search for: maythrow

...) 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 cleanup ret i32 1 } declare i32 @__gxx_personality_v0(...) Instruction:: mayThrow returns false for the invoke. This is because ... bool Instruction::mayThrow() const { if (const CallInst *CI = dyn_cast<CallInst>(this)) return !CI->doesNotThrow(); return isa<ResumeInst>(this); } CallInst != InvokeInst, and invokeinst is not derived from callinst....

...er_zero()) { > ... > } > > we can test that the %c does not dominate %x, and so the metadata needs to be ignored. The complication here is that you may need to encode all conditional branch inputs along all paths from the entry to the value, and the scheme also needs to deal with maythrow functions. This does not need to be resolved to move forward with Pekka’s proposal, but since we’re talking about it... - The control dependent metadata looks like it could work, I like the idea (although we’re lacking a strong motivation) - I’m not sure why divide-by-zero would motivate this (p...

Hi Andy, Andrew Trick wrote: > At some point I stopped thinking about this as a bug and realized that > you just need to think of LLVM as modeling speculative code barriers as > memory dependence. In LLVM, it makes no sense to have a readonly > may-throw call. The problem is that that model breaks down with aggressive aliasing like: void foo(int* restrict ptr) { *ptr = 40;

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

...more low level, call it "ExtendedBBInfo" or something, and rename what it provides to be more clearly structural: A. Inst * FirstIsGuaranteedToTransferExecutionToSuccessor(BB) (naming bikeshed open on this one :P) B. Inst * LastIsGuaranteedToTransferExecutionToSuccessor(BB) C. Inst *FirstMayThrow(BB) D. Inst *LastMayThrow(BB) Most things want to know if a given inst is before or after these. Since we have to touch the entire set of instructions for a bb anyway, we could also provide dominates (like orderedbasicblock) to give you the answer to that question for free (otherwise everything...

...) { > ... > } > > we can test that the %c does not dominate %x, and so the metadata > needs to be ignored. The complication here is that you may need to > encode all conditional branch inputs along all paths from the entry > to the value, and the scheme also needs to deal with maythrow > functions. > > > > This does not need to be resolved to move forward with Pekka’s > proposal, but since we’re talking about it... > *If* we're going to introduce metadata with implied control dependencies, then we need to figure this out. Otherwise, yes. > >...

...============================================================== >>> --- llvm/trunk/include/llvm/IR/Instruction.h (original) >>> +++ llvm/trunk/include/llvm/IR/Instruction.h Tue Feb 19 14:02:09 2013 >>> @@ -309,6 +309,12 @@ public: >>> /// >>> bool mayThrow() const; >>> >>> + /// mayReturn - Return true if this is a function that may return. >>> + /// this is true for all normal instructions. The only exception >>> + /// is functions that are marked with the 'noreturn' attribute. >>> + /// >&...

...lvm/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 > ___________...

.... As for (2), the dwarf writer scans all instructions in the function and if it sees a call that is not bracketed by labels then it generates an appropriate entry in the exception table (this will of course need to be modified to consider all throwing instructions - note that this means that "maythrow" markings will have to exist right to the end of code generation!); it is done this way because labels inhibit optimizations (we used to bracket all calls with labels, but stopped doing that because of the optimization problem). I'm mentioning this because the begin and end labels are not...

> I've never realy understood how the llvm.invariant intrinsics could be > put into practice. There is the problem that "end" can occur anywhere > as you suggested fixing with a flag. I was under this impression too, but after re-reading the language reference I'm not so sure -- it says about invariant.start: "This intrinsic indicates that until an

...s <listmail at philipreames.com> >> wrote: >> >> Joining in very late, but the tangent here has been interesting (if >> rather OT for the original thread). >> >> I agree with Danny that we might want to take a close look at how we >> model things like maythrow calls, no return, and other implicit control >> flow. I'm not convinced that moving to a pure explicit model is the right >> idea because we get a lot of gain in practice from being able to reason >> about what are essentially a limited form of extended basic blocks. I >&...

...*ptr; bar(ptr); } while (i++ < *ptr); return result; } Say we have a front end that declares bar as... declare void @bar(i32*) readonly; So 'bar' is 'readonly' and 'may-unwind'. When LICM tries to hoist the load it interprets the 'may-unwind' as "MayThrow" in LICM-language and bails. However, when it tries to sink the call itself it sees the 'readonly', assumes no side effects and sinks it below the loads. Hmm... There doesn't appear to be a way to declare a function that is guaranteed not to write to memory in a way that affects t...

...> return result; > } > > Say we have a front end that declares bar as... > > declare void @bar(i32*) readonly; > > So 'bar' is 'readonly' and 'may-unwind'. > > When LICM tries to hoist the load it interprets the 'may-unwind' as "MayThrow" in LICM-language and bails. However, when it tries to sink the call itself it sees the 'readonly', assumes no side effects and sinks it below the loads. Hmm... is your worry here about the following case? - the load will trap if executed - bar throws an exception Thus with the or...

...gt; >> Say we have a front end that declares bar as... >> >> declare void @bar(i32*) readonly; >> >> So 'bar' is 'readonly' and 'may-unwind'. >> >> When LICM tries to hoist the load it interprets the 'may-unwind' as "MayThrow" in LICM-language and bails. However, when it tries to sink the call itself it sees the 'readonly', assumes no side effects and sinks it below the loads. Hmm... > > is your worry here about the following case? > - the load will trap if executed > - bar throws an exception...

...On Jul 21, 2016, at 7:45 AM, Philip Reames <listmail at philipreames.com> wrote: > > Joining in very late, but the tangent here has been interesting (if rather OT for the original thread). > > I agree with Danny that we might want to take a close look at how we model things like maythrow calls, no return, and other implicit control flow. I'm not convinced that moving to a pure explicit model is the right idea because we get a lot of gain in practice from being able to reason about what are essentially a limited form of extended basic blocks. I would welcome a design discussio...

...t sees a > call that is not bracketed by labels then it generates an appropriate entry > in the exception table Do you mean "that _is_ bracketed by labels" ? > (this will of course need to be modified to consider > all throwing instructions - note that this means that "maythrow" markings will > have to exist right to the end of code generation!); it is done this way > because labels inhibit optimizations (we used to bracket all calls with > labels, but stopped doing that because of the optimization problem). I'm > mentioning this because the begin an...

...sion 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 not recursive...

...c = call z_is_never_zero()) { ... } we can test that the %c does not dominate %x, and so the metadata needs to be ignored. The complication here is that you may need to encode all conditional branch inputs along all paths from the entry to the value, and the scheme also needs to deal with maythrow functions. Given that the common use case for this seems like it will be for some language frontend to add !notrap to *all* instances of some kind of instruction (divisions, load, etc.), I think that adding a new flag (like the nsw flag) may be more appropriate for efficiency reasons. Even easier,...

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

Hi everyone, In order to have exceptions for non-call instructions (such as sdiv, load or stores), I'm modifying codegen so that it generates a BeginLabel and an EndLabel between the "may throwing" instruction. This is what the codegen of an InvokeInst does. However, when generating native code, only BeginLabel is generated, and it is generated after the instruction. I'm not