[M3devel] further removal of volatile

[Tony Hosking]

But what sort of code do you get not using the BIT_FIELD_REF?


On 5 Jun 2010, at 16:52, Jay K wrote:

> 
> Tony, Currently we still put volatile on all floating point loads and/or stores.
> I removed it from all the other types.
> The main problem I was having is that CopySign in m3core would fail to compile.
>  It is loophoing a float as a struct with bitfields I believe.
>   I didn't look at what the equivalent C tree would be, though that is probably a good idea.
> 
> 
> With this it seems I don't need the volatile:
> 
> 
> static void
> m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>            bool volatil)
> {
>   if (o != 0 || TREE_TYPE (v) != src_t)
>   {
>     if (GCC42 || (src_T != dst_T))   <<< 
>     {
>       /* failsafe, but inefficient */
>       v = m3_build1 (ADDR_EXPR, t_addr, v);
>       v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>       v = m3_build1 (INDIRECT_REF, src_t,
>       m3_cast (m3_build_pointer_type (src_t), v));
>     }
>     else
>     {
>       v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>                      bitsize_int (o));
>     }
>   }
>  ...
> 
> 
> 
> static void
> m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>             bool volatil)
> {
>   tree val;
>   if (o != 0 || TREE_TYPE (v) != dst_t)
>   {
>     if (GCC42 || (src_T != dst_T))   <<<< 
>     {
>       /* failsafe, but inefficient */
>       v = m3_build1 (ADDR_EXPR, t_addr, v);
>       v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>       v = m3_build1 (INDIRECT_REF, dst_t,
>                      m3_cast (m3_build_pointer_type (dst_t), v));
>     }
>     else
>     {
>       v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>                      bitsize_int (o));
>     }
>   }..
> 
> Previously, the code was the equivalent of saying if GCC42 there.
> 
> 
> Good enough?
> 
> 
> You know, this bitfield stuff has been a recurring problem.
> 
> I could probably narrow it down more.
>   Like maybe if the types are the same size or both integers, still go down the old faster path.
>     Though I thought I had tried if they were either float going slow and that didn't work.
>      It might relate to structs as well.
> 
> 
> However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
> But I could look a bit at the code.
> 
> 
>  - Jay
>