[llvm-commits] [Patch] Teach basic alias analysis about inline asm "memory" clobber

[Chris Lattner]

On Mar 29, 2012, at 7:14 AM, Richard Osborne wrote:

> On 28/03/12 20:53, Richard Osborne wrote:
>> 
>> However after a bit more thought I'm worried about another problem. If we return OnlyAccessesArgumentPointees then there will be no dependence between two inline asm calls with the "sideeffect" keyword without the "memory" clobber if we can prove that none of the arguments of the first inline asm call can alias any of the arguments of the second inline asm call. This would allow us to motion one of the asm calls around the other. However based on the description of volatile asm I'm not sure if this would be valid. This makes me think I should look at modifying the getModRefInfo(ImmutableCallSite CS, const Location &Loc) method instead.
> The updated patch fixes this problem. It introduces the concept of "InvisibleMemory" - memory which can never be accessed via a load or store via pointer. This allows us to reason about instructions / calls with side effects that would prevent (for example) reordering the calls around each other but shouldn't inhibit optimizations of loads / stores.
> 
> Does this seem like a reasonable approach?

I'm somewhat concerned about this.  The aliasanalysis interface is really for reasoning about memory dependences, not other general dependences.  For example, if we ever introduce floating point rounding mode awareness to FP operations, we wouldn't model the dependences in the AA interface.

Is there some specific problem that you're seeing that motivates InvisibleMemory?

-Chris