search for: mayhavesideeffect

...: "Reid Kleckner" <rnk at mit.edu> To: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday, May 10, 2010 9:38:47 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] All CallInsts mayHaveSideEffects This is a known bug: http://llvm.org/bugs/show_bug.cgi?id=965 There has been some discussion about it and similar problems, and the desire is to perform some analysis on functions to determine if they are known to halt trivially, ie they have no loops and call no other functions that are not kno...

Hi, All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on i...

...>> On 19/02/13 21:02, Nadav Rotem wrote: >>> Author: nadav >>> Date: Tue Feb 19 14:02:09 2013 >>> New Revision: 175553 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=175553&view=rev >>> Log: >>> >>> Fix a bug in mayHaveSideEffects. Functions that do not return are now considered as instructions with side effects. >> >> what's special about functions where we were able to tell it doesn't return, >> as compared to functions that don't return but we weren't clever enough to >> realize it...

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

Hello, This patch fixes PR4174. Two test-cases included: original one from bugzilla and a little bit complicated made be myself. It seems that LoopIndexSplit doesn't handle some cases, I'll try to send some patch this week. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr4174.patch Type: application/octet-stream Size:

...;> Hello, >>>> >>>> This patch fixes PR4174. Two test-cases included: original one from >>>> bugzilla >>>> and a little bit complicated made be myself. >>> >>> I think you want isSafeToSpeculativelyExecute rather than >>> mayHaveSideEffects. Otherwise, looks fine. >> >> With isSafeToSpeculativelyExecute "make check" fails on some tests, >> i.e: >> test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll >> because of PHI (isSafeToSpeculativelyExecute == false). > > isSafeToSpeculativ...

...174. Two test-cases included: original one >>>>>> from >>>>>> bugzilla >>>>>> and a little bit complicated made be myself. >>>>> >>>>> I think you want isSafeToSpeculativelyExecute rather than >>>>> mayHaveSideEffects. Otherwise, looks fine. >>>> >>>> With isSafeToSpeculativelyExecute "make check" fails on some >>>> tests, i.e: >>>> test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll >>>> because of PHI (isSafeToSpeculativelyExecute...

...;>>>>>> one from >>>>>>>> bugzilla >>>>>>>> and a little bit complicated made be myself. >>>>>>> >>>>>>> I think you want isSafeToSpeculativelyExecute rather than >>>>>>> mayHaveSideEffects. Otherwise, looks fine. >>>>>> >>>>>> With isSafeToSpeculativelyExecute "make check" fails on some >>>>>> tests, >>>>>> i.e: >>>>>> test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll >...

...16rr : Pseudo<(outs GR16:$dst), (ins GR16:$src), "mov.w\t{$src, $dst}", [ ]>; Because it's an empty dag pattern[ ], by what does instuction selector select intruction 'MOV16rr'? 2 let canFoldAsLoad = 1, isReMaterializable = 1, mayHaveSideEffects = 1 in { def MOV16rm : Pseudo<(outs GR16:$dst), (ins memsrc:$src), "mov.w\t{$src, $dst}", [(set GR16:$dst, (load addr:$src))]>; } Please gvie me an explaination of the property IsReMaterialiable and the benefit if it is true with a simple sample 3...

...;> >>>>> This patch fixes PR4174. Two test-cases included: original one from >>>>> bugzilla >>>>> and a little bit complicated made be myself. >>>> >>>> I think you want isSafeToSpeculativelyExecute rather than >>>> mayHaveSideEffects.  Otherwise, looks fine. >>> >>> With isSafeToSpeculativelyExecute "make check" fails on some tests, i.e: >>> test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll >>> because of PHI (isSafeToSpeculativelyExecute == false). >> >> isSaf...

Currently LLVM 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...

...xes PR4174. Two test-cases included: original one from >>>>>>> bugzilla >>>>>>> and a little bit complicated made be myself. >>>>>> >>>>>> I think you want isSafeToSpeculativelyExecute rather than >>>>>> mayHaveSideEffects.  Otherwise, looks fine. >>>>> >>>>> With isSafeToSpeculativelyExecute "make check" fails on some tests, >>>>> i.e: >>>>> test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll >>>>> because of PHI (isSafeToSp...

While improving ADCE, i notice that for declare i32 @strlen(i8*) readnone define i32 @test() { ; invoke of pure function should not be deleted! invoke i32 @strlen( i8* null ) readnone to label %Cont unwind label %Other ; <i32>:1 [#uses=0] Cont: ; preds = %0 ret i32 0 Other: ; preds = %0 %exn = landingpad {i8*, i32} personality i32 (...)* @__gxx_personality_v0

...ginal one from >>>>>>>>> bugzilla >>>>>>>>> and a little bit complicated made be myself. >>>>>>>> >>>>>>>> I think you want isSafeToSpeculativelyExecute rather than >>>>>>>> mayHaveSideEffects.  Otherwise, looks fine. >>>>>>> >>>>>>> With isSafeToSpeculativelyExecute "make check" fails on some tests, >>>>>>> i.e: >>>>>>> test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll >>>&gt...

...not to go into infinite recursion in the face of PHI nodes. Also, be careful of side effects, both in the instructions you're comparing and in anything in between; for example you don't want two loads to be considered equal if there's a store to that memory in between them. Instruction::mayHaveSideEffects() and Instruction::mayReadFromMemory() are probably useful here. If you go with either of the last two options and create a function to figure out whether two values are equivalent, it might be interesting if you submitted a patch for your changes so others can use them too. Also, you'd likel...

..., returning: use isCall/isReturn/isBranch. Now you initially reported that "TableGen will (correctly) complain about 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 bette...

...16rr : Pseudo<(outs GR16:$dst), (ins GR16:$src), "mov.w\t{$src, $dst}", [ ]>; Because it's an empty dag pattern[ ], by what does instuction selector select intruction 'MOV16rr'? 2 let canFoldAsLoad = 1, isReMaterializable = 1, mayHaveSideEffects = 1 in { def MOV16rm : Pseudo<(outs GR16:$dst), (ins memsrc:$src), "mov.w\t{$src, $dst}", [(set GR16:$dst, (load addr:$src))]>; } Please gvie me an explaination of the property IsReMaterialiable and the benefit if it is true with a simple sample 3...

Hi Reid, Thank you for your response. In my analysis, I will always have entry(2) and exit(2). I will not run into cases involving entry (1+1) or entry (fn return values). I am having trouble trying to compare the arguments of entry and exit in the following scenario. #include<stdio.h> #include<stdlib.h> #include<pthread.h> struct sa { int a; pthread_mutex_t *mutex1;

...mal: ret i32 0 unwind: %t = landingpad 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 instan...

...b Staszak<kuba at gcc.gnu.org> > wrote: >> Hello, >> >> This patch fixes PR4174. Two test-cases included: original one from >> bugzilla >> and a little bit complicated made be myself. > > I think you want isSafeToSpeculativelyExecute rather than > mayHaveSideEffects. Otherwise, looks fine. With isSafeToSpeculativelyExecute "make check" fails on some tests, i.e: test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll because of PHI (isSafeToSpeculativelyExecute == false). >> It seems that LoopIndexSplit doesn't handle some cases, I...