[llvm-commits] [Patch] Teach basic alias analysis about inline asm "memory" clobber
richard at xmos.com
Mon Apr 2 03:20:14 PDT 2012
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?
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
Richard Osborne | XMOS
More information about the llvm-commits