RE: tree-sra.c and BIT_FIELD_REF?

[Jay K <jay dot krell at cornell dot edu>]

  > On Tue, Jun 12, 2012 at 03:57:44PM +0000, Jay K wrote:
  > > 
  > > Our front end is wierd.
  > > The input is unusually low level, and so are the trees it produces.
  > > I do have a hankering to fix that (or maybe just to output more portable C...)
  > > But for now:
  > > It doesn't use component_refs, and doesn't
  > > define types much, but uses either
  > > either (type*)(base + offset) or bitfield_ref(base, offset, size).
  > > 
  > > As such, it runs into occasional problems.
  > > I have had to turn off various optimizations with e.g.:
  > >  flag_tree_sra = false
  > > in langhook_post_options.
  > > 
  > > Looking at this briefly, I think I see one of the problems.
  > > tree-sra.c looks for component_refs to bitfields, but
  > > it doesn't look for bitfield_refs. It should?
  > 
  > I am not sure what you mean, if you search for the sting BIT_FIELD_REF
  > in tree-sra.c, you'll quickly find the places where we "look for" them
  > (or perhaps I should write look through them). The most important
  > ones are in functions build_access_from_expr_1 and especially
  > sra_modify_expr.
  > 
  > Having said that, Andrew Pinski has reported problems with SRA's
  > handling of BIT_FIELD_REF in another special setup, so perhaps you
  > have similar problems. Please have a look at the thread starting with
  > message: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00009.html
  > 
  > So far it however looks that, if we ever come across such problems on
  > trunk, we'll disable SRA for aggregate parts which are written to by a
  > BIT_FIELD_REF on a left hand side, mainly because we do not consider
  > them important for performance critical code.
  > 
  > Thanks,
  > 
  > Martin

 

  create_access is where I noticed it.   

 

 

  Yeah, I know my report is vague and crummy.  

  Maybe I should put together somesuch "hardcoded tree frontend" to demonstrate it.  

  I don't think the trees I'm thinking of are producible from C, unless maybe via a gcc extension?    

  I'll look later..like..I wonder where BIT_FIELD_REF would be used at all in a normal frontend.  

       If I can find one, I'll maybe try to put together a test case for it. 

  We do use them for reads and writes.  

  Even for things like picking out exponent/mantissa from floats .. well, it used to.  

  I changed it to prefer *(type*)(base + offset) when either base or type is floating point.  

 

 

  Longer story:  

  I changed to use *(type*)(base + offset) for floating point because we used to make  

  everything addressable/volatile. Then all optimizations "worked" -- no internal compiler  

  errors, bus errors, etc., but of course the code quality stunk. Though better with bit_field_ref  

  than *(type*)(base + offset).  

  In removing the addressable/volatile, I then had to work through  

  the compiler errors, incorrect code, etc., disabling optimizations selectively,  

  changing our trees some.  

  I understand we generate weird trees, so I try not to complain too much.  

 

 

Thank you,

 - Jay