search for: maywritetomemory

The Instruction::mayWriteToMemory() member function is quite useful (I'm currently writing code that will break up basic blocks at read/write instructions). Is there a safe way to do the same thing for reads from memory? It's easy enough to check for the relevant instructions, but I thought this might be a nice-to-have...

...lueList.push_back(GEPI); }; }; To find the first instructions which are not depending on others results. So far it seems to be working but i am missing instructions like: %tmp.1 = seteq int %argc, 2 ; <bool> [#uses=1] There seems only an function like llvm::Instruction::mayWriteToMemory but nothing like llvm::Instruction::mayReadFromMemory or s.t. with similiar functionality? Or else: if there is an even easier way to get the non data depending instruction from a block i missed, i would be also happy. Thanks S.T.

...struction.h (revision 102637) +++ include/llvm/Instruction.h (working copy) @@ -245,7 +245,9 @@ /// instructions which don't used the returned value. For cases where this /// matters, isSafeToSpeculativelyExecute may be more appropriate. bool mayHaveSideEffects() const { - return mayWriteToMemory() || mayThrow(); + const unsigned opcode = getOpcode(); + return mayWriteToMemory() || mayThrow() || + opcode == Call || opcode == Invoke; } /// isSafeToSpeculativelyExecute - Return true if the instruction does not Sincerely yours, Tom

..., Silken Tiger wrote: > To find the first instructions which are not depending on others results. So > far it seems to be working but i am missing instructions like: > %tmp.1 = seteq int %argc, 2 ; <bool> [#uses=1] > There seems only an function like llvm::Instruction::mayWriteToMemory > but nothing like llvm::Instruction::mayReadFromMemory or s.t. with similiar > functionality? > > Or else: if there is an even easier way to get the non data depending > instruction from a block i missed, i would be also happy. I'm not sure what you're looking for. LLVM ha...

...37) > +++ include/llvm/Instruction.h  (working copy) > @@ -245,7 +245,9 @@ >   /// instructions which don't used the returned value.  For cases where this >   /// matters, isSafeToSpeculativelyExecute may be more appropriate. >   bool mayHaveSideEffects() const { > -    return mayWriteToMemory() || mayThrow(); > +    const unsigned opcode = getOpcode(); > +    return mayWriteToMemory() || mayThrow() || > +      opcode == Call || opcode == Invoke; >   } > >   /// isSafeToSpeculativelyExecute - Return true if the instruction does not > > Sincerely yours, > Tom &g...

...o hoist >      // something that might trap, but isn't safe to hoist something > that reads >      // memory (without proving that the loop doesn't write). >      if (L->hasLoopInvariantOperands(Inst) && >          !Inst->mayReadFromMemory() && !Inst->mayWriteToMemory() && >          !isa<TerminatorInst>(Inst) && !isa<DbgInfoIntrinsic>(Inst)) { >        Inst->moveBefore(LoopEntryBranch); >        continue; >      } > > The above code happily moves an alloca instruction out of the loop, to > the new loop header....

Hi Chuck, > I need to figure out all LLVM Instructions that may write to memory. I->mayWriteToMemory() Ciao, Duncan.

...all) that can access global memory, but doesn't address the issues of accessing stack frames or stack objects. Thank you for the hint. Chuck On 1/22/2011 6:17 AM, Duncan Sands wrote: > Hi Chuck, > >> I need to figure out all LLVM Instructions that may write to memory. > I->mayWriteToMemory() > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...removes infinite recursion in readnone functions as dead code. I assume this falls under the same language rules that allow removal of infinite loops. But I need to be certain. Can someone confirm? Standard citations welcome. Otherwise this is wrong: bool mayHaveSideEffects() const { return mayWriteToMemory() || mayThrow() || !mayReturn(); } Note: For non-C support, it would be nice to have another attribute, maynotreturn (in C everything is mustreturn by default). In theory, if we had that, the C frontend could use it for potentially recursive calls, forcing the optimizer to either prove it's...

On 19.03.2016 16:25, Mehdi Amini wrote: > Hi, > > Can you elaborate what is the impact at the IR level? > If the point is just about how you lower for you target, why are you needing an IR level attribute? You backend if free to specialize the lowering for any intrinsic regardless the IR level attributes. As I explained in my reply to Philip, what I really need is a way to get

Prakash Prabhu wrote: > Hi all, > > Would it be correct to say that the only instructions in LLVM IR that > modify/access memory potentially are the following: > I believe that every instruction has a mayWriteToMemory()/mayReadToMemory() method that you can use to determine this information. See http://llvm.org/doxygen/classllvm_1_1Instruction.html (the LLVM doxygen info on llvm::Instruction) for more details. I believe these methods describe whether memory is read/written in a way visible from the LLVM I...

Hi all, Would it be correct to say that the only instructions in LLVM IR that modify/access memory potentially are the following: (1) LoadInst : Ref (2) StoreInst : Mod (3) VAArgInst : Ref (?) (4) AllocaInst : Mod (5) MallocInst : Mod (6) FreeInst : Mod (7) CallInst : Mod/Ref ? Also, my earlier impression was that the GEP instruction only computes the effective address and does not

...e >>> @@ -316,7 +322,7 @@ public: >>> /// instructions which don't used the returned value. For cases where this >>> /// matters, isSafeToSpeculativelyExecute may be more appropriate. >>> bool mayHaveSideEffects() const { >>> - return mayWriteToMemory() || mayThrow(); >>> + return mayWriteToMemory() || mayThrow() || !mayReturn(); >>> } >>> >>> /// clone() - Create a copy of 'this' instruction that is identical in all >>> >>> Modified: llvm/trunk/lib/IR/Instruction.cpp >&...

...is means it is safe to hoist // something that might trap, but isn't safe to hoist something that reads // memory (without proving that the loop doesn't write). if (L->hasLoopInvariantOperands(Inst) && !Inst->mayReadFromMemory() && !Inst->mayWriteToMemory() && !isa<TerminatorInst>(Inst) && !isa<DbgInfoIntrinsic>(Inst)) { Inst->moveBefore(LoopEntryBranch); continue; } The above code happily moves an alloca instruction out of the loop, to the new loop header. Shouldn't we also check o...

...ad i32 cleanup ret i32 %t } since it gets rid of a `resume` and thus a side effect (by assumption). # We're probably already there (but we need an audit) All said and done, the situation is not as "loosey goosey" as I made it sound like. mayHaveSideEffects() is defined as "mayWriteToMemory() || mayThrow()"; and this shows in e.g. EarlyCSE which will refuse to DCE the call to @f in @g declare void @f() readnone define void @g() { call void @f() ret void } unless @f is also marked nounwind. I've already fixed the one other instance I was aware of in https://reviews.llv...

Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff

I need to figure out all LLVM Instructions that may write to memory. In http://llvm.org/docs/tutorial/OCamlLangImpl7.html, it mentions that "In LLVM, all memory accesses are explicit with load/store instructions, and it is carefully designed not to have (or need) an "address-of" operator." I take this as "StoreInst is the only one that writes to memory". However,

Hello, I'm working with a pass that operates at the LLVM IR level. I need to run some statistics on instructions that access memory, and I'm wondering, at the IR level, which instructions aside from Load and Store access memory directly as a result of their operation? I know on an ISA level, this varies from arch to arch, but I'm wondering how LLVM has this set up at the IR level.

...: > > To find the first instructions which are not depending on others results. > > So far it seems to be working but i am missing instructions like: > > %tmp.1 = seteq int %argc, 2 ; <bool> [#uses=1] > > There seems only an function like llvm::Instruction::mayWriteToMemory > > but nothing like llvm::Instruction::mayReadFromMemory or s.t. with > > similiar functionality? > > > > Or else: if there is an even easier way to get the non data depending > > instruction from a block i missed, i would be also happy. > > I'm not sure wha...

...a mismatch of mayLoad and hasSideEffects", I believe this is incorrect considering the above description. -- Mehdi > > At the IR level, the definition of "mayHaveSideEffects" is more coherent with what I expect: > > bool mayHaveSideEffects() const { > return mayWriteToMemory() || mayThrow() || !mayReturn(); > } > >> Indeed, write-only without an ArgMemOnly property may well be useless at the IR level. If you think that there is a better way to explain the situation to TableGen, please let me know. > > I don't really understand why an MI which i...