Re: Problem with your new SRA code

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    As an aside, am I wrong in thinking that

      types__entity_id___XDLU_0__99999999<D364> bin_op_types<D1060>[18];
      ...
      T.17<D1139>_136 = VIEW_CONVERT_EXPR<types__entity_id___XDLU_0__99999999<D364>[18]>(bin_op_types<D1060>)[T.16<D1138>_135]{lb: 26 sz: 4};
    
    is a VIEW_CONVERT_EXPR to its own type?  

It sure looks that way, though I can't easily find the actual tree and
check.

    Seems like maybe we want the gimplifier to strip these if the inner
    and outer types are types_compatible_p.

If it's really to the *same* type, it shouldn't have been made at all.

Now that I'm looking at trees a lot, I see far too many VIEW_CONVERT_EXPRs
and they are going to have a negative effect on code quality.  I want
to understand what they all are.  It might be conversions to variant types,
but I think I can eliminate them.  If I have a readonly decl, I'm been
making a type variant for that and making the decl be that type, but I
think that's clearly wrong.  Likewise for volatile and actually also
in the case where DECL_SIZE or DECL_ALIGN is larger than that of the type.

I think that will eliminate a lot of them.