This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Your June 7 change to expand_expr



  In message <9806302343.AA14503@vlsi1.ultra.nyu.edu>you write:
  >     In particular, to the bit about a dereference of a REFERENCE_TYPE be
  >     always considered to be in a structure.  I don't know exactly *why*
  >     this was causing the problem, although I'm guessing it's because EGCS
  >     does some alias analysis that looks at MEM_IN_STRUCT_P.
  > 
  > The fundamental problem is that there needs to be a "conservative"
  > setting, one for which we can safely make things without risking
  > bugs.  This used to be the case when that bit is true.
?  I'm not aware of any time in the recent (gcc2 era) past where the
MEM_IN_STRUCT_P bit had that meaning.

Why?  Because the old alias code (as far as I know) has always used
MEM_IN_STRUCT_P to help with alias analysis.

  >     also seems suspicious to me.  Besides the reference issue, how do we
  >     know whether the NOP_EXPR was the degenerate addition case mentioned?
  > 
  > We can't.  That's the whole problem with the flag.
Right.  MEM_IN_STRUCT_P has fundamental flaws.  No doubt about it;
particularly since some code (ie cse) will change the bit (980506-2.c
in the egcs testsuite is an example)


  >     Jeff, for now I recommend the following patch to EGCS.
  > 
  > My recommendation, since EGCS is getting much better alias analysis,
  > is simply to *delete* the flag since it's totally impossible to set
  > it accurately and it becomes much less relevant with better alias
  > analysis.
The question then becomes "has egcs's alias analysis progressed far
enough to remove the that flag?".  I don't know the answer.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]