[M3devel] further removal of volatile

[Jay K]

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