search for: returns_twice

Hello, I am not sure about the semantic (if any) of returns_twice and noreturn attributes. int fork() __attribute__((returns_twice)); void join(int) __attribute__((noreturn)); int f(int n) { int t = fork(); n++; if (t != 0) join(t); return n; } Produces the following LLVM IR: ; Function Attrs: nounwind uwtable define i32 @f(i32 %n) local_unnamed_a...

On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: > > Hello, > > I am not sure about the semantic (if any) of returns_twice and noreturn > attributes. > > int fork() __attribute__((returns_twice)); > void join(int) __attribute__((noreturn)); > > int f(int n) { > int t = fork(); > n++; > if (t != 0) > join(t); > return n; > } > > Where the n++ has been moved after the...

...orrectly either -- see > https://bugs.llvm.org/show_bug.cgi?id=27190 Haha, I wondered for a minute whether I should bring up that bug... We've seen pretty nasty crashes due to it and had to work around it..... One of my recent work has also uncovered another (I believe) invalid handling of returns_twice functions.... https://bugs.llvm.org/show_bug.cgi?id=35211 noalias returns seems to be treated as stack allocation but is not required by either LangRef or C standard to be so for returns_twice function handling.... > IMO the Right(TM) fix is to add a CFG edge from all possibly > longjmp'...

...vm-dev at lists.llvm.org> wrote: >> On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: >>> >>> Hello, >>> >>> I am not sure about the semantic (if any) of returns_twice and noreturn >>> attributes. >>> >>> int fork() __attribute__((returns_twice)); >>> void join(int) __attribute__((noreturn)); >>> >>> int f(int n) { >>> int t = fork(); >>> n++; >>> if (t != 0) >>>...

...xpect to get to it anytime soon; that's why I'm giving it to them for now. If you don't want this to happen, you better speak up now. > > Chip > > Begin forwarded message: > >> From: Patrick Walton <pwalton at mozilla.com> >> Subject: Re: [patch] Add the returns_twice attribute >> Date: September 29, 2011 4:43:52 PM MDT >> To: Rafael Ávila de Espíndola <rafael.espindola at gmail.com> >> Cc: llvm-commits <llvm-commits at cs.uiuc.edu>, Charles Davis <cdavis at mymail.mines.edu> >> >> On 9/29/11 3:42 PM, Rafael Ávila...

Hello LLVM-dev, I think I've found an issue with the MachineSink optimization on a program that uses setjmp. It looks like MachineSink will happily move a machine instruction into a following machine basic block (not necessarily a successor), even when that later block can be reached through a setjmp. Here is some example debug output from llc that I'm seeing: Sinking along critical

...e., without any regard to a C standard, to the extent that LLVM IR behaviour can be considered to be unrelated to any C standard). My question is: is this a bug in LLVM, or is this behaviour deemed to be by design? Also: our setjmp is not called setjmp, but we do mark its replacement also as "returns_twice". So even if the above behaviour would be considered "expected" for setjmp, would the same go for any function marked as "returns_twice"? I tested with clang/LLVM 3.7.0 and the clang from 7.0.1. I don't have newer versions available here. Thanks, Jonas (*) The only...

On Oct 4, 2011, at 8:23 PM, Khaled ElWazeer wrote: > Actually my problem is solved when I added "__sigsetjmp" to this list. Rafael just added a returns_twice function attribute to LLVM IR. I expect he will update the callsFunctionThatReturnsTwice() function soon. /jakob

In the long list of globals that are now in the TargetOptions struct, I noticed this one was misspelled. llvm::LessPrecideFPMAD() And now that I look it over w/ spellcheck: ARM Architecural Reference pre-unfied returns_twice fo functions

Actually my problem is solved when I added "__sigsetjmp" to this list. Thanks, -Khaled On Tue, Oct 4, 2011 at 10:27 PM, Khaled ElWazeer <khalid.alwazeer at gmail.com>wrote: > > That code should do it, but I realized you only detect setjmp functions by > name. My code is calling "__sigsetjmp" not "segsetjmp". You only support > these functions:

Just wanted to confirm that I too like where this is going. =] I think Philip and others have really handled the bulk of the review, and I'm very comfortable with them finishing the patch review. One issue where I wanted to chime in, hopefully just to add some clarity, is the "readonly" vs operand bundle set of (interrelated) issues. First, as I think Philip already said, I think

...lvm.org%2FD77767&data=02%7C01%7Ctentzen%40microsoft.com%7C33176bc44b81431207c808d7e1e5e5d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637226249850794040&sdata=M%2B8lCeJRufD5FuQvUqAkn1GwKBNBvm2DV9YDlockYBc%3D&reserved=0> for the sort of issues that come up. Note that we mark setjmp returns_twice, which turns off certain optimizations. I don’t really like extending the usage of this sort of construct further, but if we are going to, we should at least mark the new intrinsics returns_twice, so they get the same protection as setjmp. -Eli From: Ten Tzen <tentzen at microsoft.com<mail...

That code should do it, but I realized you only detect setjmp functions by name. My code is calling "__sigsetjmp" not "segsetjmp". You only support these functions: static const char *ReturnsTwiceFns[] = { "_setjmp", "setjmp", "sigsetjmp", "setjmp_syscall", "savectx", "qsetjmp",

...lvm.org%2FD77767&data=02%7C01%7Ctentzen%40microsoft.com%7C334ed759562941d3f2ba08d7e194d0d6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637225901600853320&sdata=hTvtxO9OVy3fwzqX2EfLRb76Qb%2ByDlmdTHHLvuIrupQ%3D&reserved=0> for the sort of issues that come up. Note that we mark setjmp returns_twice, which turns off certain optimizations. I don’t really like extending the usage of this sort of construct further, but if we are going to, we should at least mark the new intrinsics returns_twice, so they get the same protection as setjmp. -Eli From: Ten Tzen <tentzen at microsoft.com<mail...

Hi, This is a spin-off of previous Windows SEH RFC below. This RFC only focus on supporting HW Exception Handling. A detailed implementation can be seen in here: https://github.com/tentzen/llvm-project/commit/8a2421c274b683051e456cbe12c177e3b934fb5e It passes all MSVC SEH suite (excluding those with “Jumping out of _finally” ( _Local_Unwind)). Thanks, --Ten **** The rules for C code: ****

On 9/7/20 10:56 AM, Nicolai Hähnle wrote: > Hi Johannes and Atmn, > > On Sat, Sep 5, 2020 at 7:07 AM Johannes Doerfert via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>  > In any case, please explain the intended behavior of the attribute and >>  > the metadata upon inlining. >> >> The attribute will be attached to the caller upon

...can think of > right now is "convergent". An incomplete list of function attributes that disable transformations (not actually checked but I expect them too):   cold, convergent, noduplicate, noimplicitfloat, nomerge, noinline,   nobuiltin, 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 >>  > &quot...