similar to: [LLVMdev] exact semantics of 'nounwind'

Hi, as a language front end developer I am a bit terrified by any "unwind here will call terminate" semantics in the IR. I'd prefer the LLVM IR to be free from any assumptions about the languages compiled to it and this looks like C++ semantics sneaking into LLVM. Thus I'm under the expression the calling terminate semantics should be implemented by the front end.

Hi Nick, > Since I'm busy muddying the waters by changing how exception handling > works, I thought I should ask for clarification on the exact behaviour > of the current 'nounwind' attribute found on functions, calls and invokes. > > I was thinking these would be similar to the AA analysis notes like > "doesNotAccessMemory" which is a provable property

Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example... int32_t foo(int32_t* ptr) { int i = 0; int result; do { bar(ptr); result = *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

On 9 Feb 2017, at 08:41, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Feb 8, 2017 at 5:45 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > What isn’t clear to me still is : why shouldn't this be transitive? > In the example you’re showing, for a caller of f() in bar, what is the advantage of knowing that f() is nounwind if it an

Andrew Trick wrote: > Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example... > > int32_t foo(int32_t* ptr) { > int i = 0; > int result; > do { > bar(ptr); > result = *ptr; > bar(ptr); > } while (i++< *ptr); > return result; > } > > Say we have

On Jul 21, 2013, at 11:55 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Andrew, > > On 22/07/13 02:56, Andrew Trick wrote: >> Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example... >> >> int32_t foo(int32_t* ptr) { >> int i = 0; >> int result; >> do {

Hi Andrew, On 22/07/13 02:56, Andrew Trick wrote: > Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example... > > int32_t foo(int32_t* ptr) { > int i = 0; > int result; > do { > bar(ptr); > result = *ptr; > bar(ptr); > } while (i++ < *ptr); > return

I'm not sure I understand why it's blocked on that, by the way. Even if we can't apply the attribute ourselves, I don't see why we wouldn't expose that ability to frontends. I'm not entirely sure "halting" is the right attribute either, by the way. What I, personally, would like to see is a way to specify a function call is safe to speculatively execute. That

On Jul 22, 2013, at 12:56 AM, Duncan Sands <baldrick at free.fr> wrote: > my understanding is different. I'm pretty sure that what I'm about to say is > the traditional way these things have been viewed in LLVM. That doesn't mean > that it's the best way to view these things. > >> - nounwind means no dwarf EH. Absence > > I guess you mean

> On Feb 8, 2017, at 12:58 PM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I think this behavior is intended to allow better LTO between C and C++. Consider this kind of code: > > // foo.h > extern "C" int doThing(bool canThrow); > // foo.cpp > int doThing(bool canThrow) { > ... > if (hadError) { > if (canThrow)

Kuperstein, Michael M wrote: > I'm not sure I understand why it's blocked on that, by the way. It blocks our ability to automatically deduce the halting attribute in the optimizer, which was necessary for the use case I had at the time. If you have a use case of your own, feel free to propose the patch! (Technically it's not *blocked* -- see how my patch does it! -- but the

On Sun, Jul 21, 2013 at 5:56 PM, Andrew Trick <atrick at apple.com> wrote: > Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example... > > int32_t foo(int32_t* ptr) { > int i = 0; > int result; > do { > bar(ptr); > result = *ptr; > bar(ptr); > } while (i++ <

Hi Andrew, On 22/07/13 09:32, Andrew Trick wrote: > > On Jul 21, 2013, at 11:55 PM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > >> Hi Andrew, >> >> On 22/07/13 02:56, Andrew Trick wrote: >>> Does 'nounwind' have semantics that inform optimization passes? It seems to >>> in some cases, but not

Of course frontends are free to put attributes, but it would be nice if optimizations actually used them. ;-) My use case is that of proprietary frontend that happens to know some library function calls - which are only resolved at link time - have no side effects and are safe to execute speculatively, and wants to tell the optimizer it can move them around however it likes. I'll gladly submit

On 22 July 2013 01:11, Kuperstein, Michael M <michael.m.kuperstein at intel.com > wrote: > Of course frontends are free to put attributes, but it would be nice if > optimizations actually used them. ;-) > My use case is that of proprietary frontend that happens to know some > library function calls - which are only resolved at link time - have no > side effects and are safe

This is a revision of the second exception handling proposal I sent out. You can see it here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036484.html After much discussion, there are some changes to the proposal – some significant and some minor. One major point, this proposal does not address the issue of catching an exception thrown from a non-invoke instruction. However if done

Kuperstein, Michael M wrote: > A patch is attached. + const CallInst* CI = dyn_cast<CallInst>(Inst); + return CI->isSafeToSpeculativelyExecute(); "return cast<CallInst>(Inst)->isSafeToSpeculativelyExecute();"? Use cast<> instead of dyn_cast<>. See http://llvm.org/docs/ProgrammersManual.html#isa . Then I don't think it needs to be two lines.

What? Yet another EH proposal?! This one is different from the others in that I'm planning to start implementing this shortly. But I want your feedback! I've all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others. Now is your turn! Please read this proposal and send me your comments, suggestions, and concerns. -bw

Hi Eli, On 22/07/13 03:37, Eli Friedman wrote: > On Sun, Jul 21, 2013 at 5:56 PM, Andrew Trick <atrick at apple.com> wrote: >> Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example... >> >> int32_t foo(int32_t* ptr) { >> int i = 0; >> int result; >> do { >>

A patch is attached. Not sure I'm happy with this due to the aforementioned orthogonality concerns, but I really don't have any better ideas. If anyone does, feel free to offer them, I don't mind throwing this patch into the trash. (Also, not happy with the name, using "speculatable" as Nick suggested, for the lack of other options. If the name stays I'll add it to the