Re: Dec alias patch causing regressions

[Jeffrey A Law <law at redhat dot com>]

  In message <10103121544.AA17732@vlsi1.ultra.nyu.edu>you write:
  >     No, that's not a complete solution.  Consider that if the memory
  >     locations do not conflict, then the scheduler may also reorder those
  >     instructions and we can get incorrect code.
  > 
  > Oh, that's right.  We are not supposed to reuse memory locations
  > unless they conflict.
Precisely.    From what I can gather, it appears that we've got a lot
more memory references with non-zero alias sets, which is generally a
good thing -- with the exception of these shared stack slots.

My suspicion is that these shared stack slots are coming from argument
setup.  When we do not inline the calls themselves will prevent this
kind of problem by acting as barriers for DSE and scheduling, but when
we inline the calls, if we have argument setup into the stack, then it's
going to be exposed to DSE and scheduling.

If my suspicions are correct, we may simply need to clear the alias sets
for argument setup.  But that's just speculation.

jeff