This is the mail archive of the gcc@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]
Other format: [Raw text]

Re: RTL alias analysis


> One way to avoid this restriction would be to extend RTL alias
> analysis to not be strictly type based.  In particular, we could
> extend it to know that a particular stack slot has a range of alias
> sets.  And we would then have to know whether a particular pointer
> could possibly point to that stack slot.  However, in general, I

This would not work in general.  You can teach RTL AA to properly answer
question "can pointer X point to slot Y?" by knowing that slot Y can
have two different alias sets, but you need to answer also question "can
pointer X point to same place as pointer Y" when both pointers might
possibly point to shared slot Z.  So if you introduce sharing and you
want to do type based AA on pointers, you would have to somehow adjust
type aliasing rules so any two types that can point to same place in
shared stack slot would be now believed to be conflicting.  This is
rather nasty I would say.
> 
> Another way to avoid this restriction would be to prevent reordering
> of reads and writes across lexical block boundaries when objects are
> being shared.  This would be another way of preventing the undesirable
> reordering of reads and writes.  However, in general, I again suspect
> that this would yield worse results.

It also seems to me that we can prety freely lifht the memory accesses
across "block" boundaries already on tree level, so reconstructing some
sort of barriers at expansion time is no longer be doable at all.

Honza


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