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

[Richard Osborne]

On 30/03/12 21:17, Chris Lattner wrote:
> 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
Currently a call that has a side effect other than accessing memory must 
be conservatively marked as having UnknownModRefBehavior. Anything more 
aggressive will result in miscompilations since there is no other 
mechanism that keeps track of the side effects of these calls. Using 
UnknownModRefBehavior prevents optimization of loads / stores around the 
call. I want some way to indicate that a call has side effects but these 
side effects don't involving reading / writing memory (or don't involve 
reading / writing memory that isn't passed to the function). Thinking of 
these other side effects as reads and writes of some otherwise 
inaccessible memory which never aliases a load or store instruction 
seemed the simplest way to handle this in the current framework.

Inline asm is one example of a call that might benefit from this. Inline 
asm may have side effects that prevent them from being eliminated / 
reordered but alias analysis could give more precise results is come 
cases based on the list of operands and clobbers. There are also a 
number of XCore Intrinsics which have side effects but don't access 
memory. For example there are intrinsics for dedicated I/O instructions 
that toggle GPIO pins. It is invalid to reorder / eliminate calls to 
these intrinsics since it would change the signal observed on the pins 
of the chip, but it is perfectly valid to motion loads and stores around 
these intrinsics.

-- 
Richard Osborne | XMOS
http://www.xmos.com