search for: willreturn

...get the current semantics back, I won't oppose that. However, all conversations up to this point seemed to indicate that we do not want this. Please see [1] and [5]. > Assuming the simple flip of polarity from the previous paragraph, what > is the difference between the existing "willreturn" and the proposed > "willprogress"? Furthermore, if there is a difference, why is it > relevant to the compiler? I mean there is plenty of cases where you have one but not the other: ``` while (1) {   atomic_add(X, 1); } ``` does make progress but will not return. More impo...

Hi all, A while back we started annotating intrinsics with new attributes ( https://reviews.llvm.org/D65377) After some discussion it was decided it would be good to have an `opt-out` attribute list for intrinsics. Some attributes that can be added to the list could be: nosync, nofree, nounwind, willreturn For now, there are 2 approaches: 1. Filtering opt-out attributes in tablegen source ( https://reviews.llvm.org/D70365) 2. Having tablegen handle opt-out list ( https://reviews.llvm.org/D70365?id=229732) How do people feel about these approaches? Is any of the two better than the othe...

...; preds = %BL.0005, %entry ret void } ; Function Attrs: norecurse readnone define dllexport void @burst.initialize(i8* (i8*)* nocapture readnone %callback) local_unnamed_addr #1 !ubaa. !0 { entry: ret void } ; Function Attrs: nounwind readnone speculatable willreturn declare float @llvm.pow.f32(float, float) #2 attributes #0 = { nofree } attributes #1 = { norecurse readnone } attributes #2 = { nounwind readnone speculatable willreturn } !ubaa.Burst.Compiler.IL.Tests.VectorsMaths\2FFloatPointer.0 = !{!0, !0, !0, !0} !0 = !{i1 false} !1 = !{i1 true, i1 false,...

...t;> >> ; Function Attrs: norecurse readnone >> define dllexport void @burst.initialize(i8* (i8*)* nocapture readnone >> %callback) local_unnamed_addr #1 !ubaa. !0 { >> entry: >> ret void >> } >> >> ; Function Attrs: nounwind readnone speculatable willreturn >> declare float @llvm.pow.f32(float, float) #2 >> >> attributes #0 = { nofree } >> attributes #1 = { norecurse readnone } >> attributes #2 = { nounwind readnone speculatable willreturn } >> >> !ubaa.Burst.Compiler.IL.Tests.VectorsMaths\2FFloatPointer.0 = !...

..., args, ""); } And before my pass finish, I print the IR, it shows I successfully add the intrinsic %5 = load i32 (i32, i32)*, i32 (i32, i32)** %1, align 8, !dbg !35, !ppp.load !36 call void @llvm.dbg.label(metadata !36), !dbg !37 ... ; Function Attrs: nounwind readnone speculatable willreturn declare void @llvm.dbg.label(metadata) #1 But, when I use llvm-dis to disassemble the .bc generated by opt, it ignore the code I insert: invalid llvm.dbg.label intrinsic variable call void @llvm.dbg.label(metadata !36), !dbg !37 !36 = !{!"dbg1", !"dbgfromLoad"} llvm-dis: war...

...ou are quite right! I'd searched "recursion" to look for bugs, but the problem (as described in #965) is more general than that. (I'm quite familiar with Haskell, in which termination vs. nontermination is discussed much more than it is in C.) The optimization and the "willreturn" suggestion make sense to me. (Is it worth commenting on the bug-report? I guess not, since I don't actually have anything to add: it's already a clear bug with a clear solution: though perhaps having more test-cases for a testsuite is useful to LLVM?) -Isaac

...   the function only contained such a loop, ... Why this way:  - The discussions before concluded IR does have a forward process    guarantee [1,5]. So we don't want to pessimize existing code.    That said, we want to exploit the property, e.g. in LoopDeletion,    during the deduction of `willreturn` (and thereby for    `isGuaranteedToTransferExecutionToSuccessor` and everything that    transitively uses it), ...  - Function attributes are the most fine-grained level, except    instructions, to provide sticky semantics. The instruction level has    however only coarse grained effects, tha...

...an help safety (dis)provers. For example, can we improve the use-after-free bug detection using some attributes? 3. Improve Liveness related capabilities of Attributor. Again I want to consider whether some attribute deduction can help liveness (dis)provers. For example NoReturn, WillReturn can be improved. I am sure these 2 attributes do not cover all the cases as it is an undecidable problem. But I was wondering whether there is room for improvement in their deduction mechanism. 4. Can we optimize the attribute deduction algorithm to reduce compile time? 5. Is...

...;>>> define dllexport void @burst.initialize(i8* (i8*)* nocapture readnone >>>> %callback) local_unnamed_addr #1 !ubaa. !0 { >>>> entry: >>>> ret void >>>> } >>>> >>>> ; Function Attrs: nounwind readnone speculatable willreturn >>>> declare float @llvm.pow.f32(float, float) #2 >>>> >>>> attributes #0 = { nofree } >>>> attributes #1 = { norecurse readnone } >>>> attributes #2 = { nounwind readnone speculatable willreturn } >>>> >>>> !ubaa.B...

...often with generic intrinsic already. We proposed the other day [1] to change the default semantics of non-target specific intrinsics such that you have to opt-in for certain effects. For the above example you want `llvm.x86.flags.write` to be `writeonly` and `inaccesiblememonly`. Also `nosync`, `willreturn`, ... Cheers, Johannes [0] https://www.youtube.com/watch?v=elmio6AoyK0 [1] http://lists.llvm.org/pipermail/llvm-dev/2019-August/134404.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: no...

...null_pointer_is_valid, optsize, optnone, returns_twice,   "thunk" Similarly there are parameter attributes that prevent transformations. >>  > Assuming the simple flip of polarity from the previous paragraph, what >>  > is the difference between the existing "willreturn" and the proposed >>  > "willprogress"? Furthermore, if there is a difference, why is it >>  > relevant to the compiler? >> >> I mean there is plenty of cases where you have one but not the other: >> ``` >> while (1) { >>    atom...

...d the other day > > [1] to change the default semantics of non-target specific intrinsics > > such that you have to opt-in for certain effects. > > > > For the above example you want `llvm.x86.flags.write` to be `writeonly` and > > `inaccesiblememonly`. Also `nosync`, `willreturn`, ... > > > > Cheers, > > Johannes > > > > > > [0] https://www.youtube.com/watch?v=elmio6AoyK0 > > [1] http://lists.llvm.org/pipermail/llvm-dev/2019-August/134404.html > > -- Johannes Doerfert Researcher Argonne National Laboratory Lemont, IL 60...

...op side-effect code to be moved before the overflowing call; otherwise it would be executed on overflow termination. How would we check whether a function can overflow the stack? Whatever the answers to these questions are, I think we should clarify what the function attributes noreturn, nounwind, willreturn mean. The most explicit way would be listing all the possible outcomes of calling a function and exclude possibilities per attribute. 1. Call returns to next instruction / invoke branches to "to" block. 2a. Call throws synchronous exception and stack is unwound to parent caller 2b. Invok...

...after-free, I don't > think there's currently any plans for it directly, but they can be I assume. > > > Improve Liveness related capabilities of Attributor. Again I want to > consider whether some attribute deduction can help liveness (dis)provers. > For example NoReturn, WillReturn can be improved. I am sure these 2 > attributes do not cover all the cases as it is an undecidable problem. But > I was wondering whether there is room for improvement in their deduction > mechanism. Liveness is certainly something that we're currently trying to > improve and I don&...

Hi Isaac, > For fun, I made a recursive function, but LLVM optimized it wrong (if > I'm understanding C standards correctly). > > "void f() { f(); }"[see llvm-code in footnote 1] > was optimized to be equivalent to "void f() {}"[also 1]. I believe it > should either be equivalent in effect to "void f() { while(1){} }"[2], > which produces an

...d the other day > > [1] to change the default semantics of non-target specific intrinsics > > such that you have to opt-in for certain effects. > > > > For the above example you want `llvm.x86.flags.write` to be `writeonly` and > > `inaccesiblememonly`. Also `nosync`, `willreturn`, ... > > > > Cheers, > > Johannes > > > > > > [0] https://www.youtube.com/watch?v=elmio6AoyK0 > > [1] http://lists.llvm.org/pipermail/llvm-dev/2019-August/134404.html > > -- Johannes Doerfert Researcher Argonne National Laboratory Lemont, IL 604...

...nk there's currently any plans for it directly, but they can be I assume. >>> >>> > Improve Liveness related capabilities of Attributor. Again I want to >>> consider whether some attribute deduction can help liveness (dis)provers. >>> For example NoReturn, WillReturn can be improved. I am sure these 2 >>> attributes do not cover all the cases as it is an undecidable problem. But >>> I was wondering whether there is room for improvement in their deduction >>> mechanism. Liveness is certainly something that we're currently trying to...

Hey everyone, I was looking into how the global optimization pass fares against things like what's reported in https://bugs.llvm.org/show_bug.cgi?id=44676 Looking at this, I think it would be pretty trivial to optimize that down given that there are already threading assumptions made: https://godbolt.org/z/u6ZqoB Is this something I can look into? Another thing is that currently *all* external

...or going down that route is that `convergent` is really an odd duck in that it is the only attribute in LLVM that _adds_ new constraints on program transforms. All other attributes _remove_ constraints on program transforms by expressing constraints on what the function does (e.g. readnone, nosync, willreturn, ...). Matt tried to push for changing that, making the "convergent" restrictions the default and adding `noconvergent` on most things, but that effort got stuck. In the meantime, let's avoid adding yet another odd duck like this :) Cheers, Nicolai > > -Hal > > On 8/9...

I tried the LLVM demo with unmodified settings http://llvm.org/demo/index.cgi (same results from llvm 2.6 with clang, `clang-cc -emit-llvm -O2 test.c`, on my Linux x86_64) For fun, I made a recursive function, but LLVM optimized it wrong (if I'm understanding C standards correctly). "void f() { f(); }"[see llvm-code in footnote 1] was optimized to be equivalent to "void f()