Hi John,> As for instructions, I don't know of an instruction which does nothing, > won't be removed by optimization, and yet does not inhibit > optimization. Perhaps a local alloca and a volatile load or store would > do the trick? Being volatile, the compiler won't remove it (or if it > does, it's a bug, and you should file a bug report), and since it loads > from a memory object not used for anything else, alias analysis should > be able to see that it doesn't interefere with any other load/store.LLVM certainly will remove volatile loads and stores to local variables (at least in simple situations). I suggest using an empty asm statement. Ciao, Duncan.
On 10/25/10 10:43 AM, Duncan Sands wrote:> Hi John, > >> As for instructions, I don't know of an instruction which does nothing, >> won't be removed by optimization, and yet does not inhibit >> optimization. Perhaps a local alloca and a volatile load or store would >> do the trick? Being volatile, the compiler won't remove it (or if it >> does, it's a bug, and you should file a bug report), and since it loads >> from a memory object not used for anything else, alias analysis should >> be able to see that it doesn't interefere with any other load/store. > LLVM certainly will remove volatile loads and stores to local variables > (at least in simple situations). I suggest using an empty asm statement.Really? Isn't that illegal? The whole point of "volatile" is to tell the compiler that it should not remove a load/store. Optimizing them away seems counter-intuitive and directly contradicts the documented behavior in the LLVM Language Reference manual (which states that the number of volatile loads/stores will not be changed). -- John T.> Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Mon, Oct 25, 2010 at 10:52 AM, John Criswell <criswell at illinois.edu> wrote:> On 10/25/10 10:43 AM, Duncan Sands wrote: >> Hi John, >> >>> As for instructions, I don't know of an instruction which does nothing, >>> won't be removed by optimization, and yet does not inhibit >>> optimization. Perhaps a local alloca and a volatile load or store would >>> do the trick? Being volatile, the compiler won't remove it (or if it >>> does, it's a bug, and you should file a bug report), and since it loads >>> from a memory object not used for anything else, alias analysis should >>> be able to see that it doesn't interefere with any other load/store. >> LLVM certainly will remove volatile loads and stores to local variables >> (at least in simple situations). I suggest using an empty asm statement. > > Really? Isn't that illegal? The whole point of "volatile" is to tell > the compiler that it should not remove a load/store. Optimizing them > away seems counter-intuitive and directly contradicts the documented > behavior in the LLVM Language Reference manual (which states that the > number of volatile loads/stores will not be changed).If a local variable doesn't escape the function, no other thread can touch it, and a volatile load from it is thus proven equivalent to a regular load.> > -- John T. > >> Ciao, >> >> Duncan. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Hi Duncan, The empty inline asm crossed my mind as well, but LLVM handles inline assemblies as calls. This would lead to a dependence if it is inside of a loop, right? And this means a considerable impact on the optimizers. Is it possible to avoid it? Thanks, Alexandra Duncan Sands wrote:> > > LLVM certainly will remove volatile loads and stores to local variables > (at least in simple situations). I suggest using an empty asm statement. > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- View this message in context: http://old.nabble.com/Prevent-instruction-elimination-tp30046067p30049449.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
Hi Alexandra,> The empty inline asm crossed my mind as well, but LLVM handles inline > assemblies as calls. This would lead to a dependence if it is inside of a > loop, right? And this means a considerable impact on the optimizers. > Is it possible to avoid it?if a statement has no side-effects then the optimizers will remove it. Thus you are obliged to have a statement with side-effects. This same problem occurred with the debug info intrinsics, and the chosen solution was to teach all the optimizers that these intrinsics didn't actually do anything (but shouldn't be removed). I think you should seek a different design. What are you really trying to do? Ciao, Duncan.