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

Richard Osborne richard at xmos.com
Wed Mar 28 12:53:29 PDT 2012


On 28 Mar 2012, at 18:58, Jim Grosbach wrote:

My understanding is that "memory" alone still is restricted to memory that's one of the operands and says that the location can be modified in an "unpredictable way." For memory not listed as an operand, "volatile" must also be specified.

-Jim

You're quite right. According to http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

"If your assembler instructions access memory in an unpredictable fashion, add `memory' to the list of clobbered registers. This will cause GCC to not keep memory values cached in registers across the assembler instruction and not optimize stores or loads to that memory. You will also want to add the volatile keyword if the memory affected is not listed in the inputs or outputs of the asm, as the `memory' clobber"

I can update the patch to check IA->hasSideEffects().

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120328/4bb5b567/attachment.html>


More information about the llvm-commits mailing list