similar to: [LLVMdev] Does nounwind have semantics?

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

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

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

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

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

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

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.

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

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

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

Hi Andy, Thanks for replying, responses inline below: On Fri, Feb 19, 2016 at 11:12 AM, Andrew Trick <atrick at apple.com> wrote: > This clearly doesn't need operand bundles, but using an intrinsic > would permit special code motion semantics. It could be hoisted and > merged with other traps, but the condition could never be widened > beyond the union of the original

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

On 01/05/2017 12:17 PM, Reid Kleckner wrote: > On Thu, Jan 5, 2017 at 9:19 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 01/05/2017 10:55 AM, Sanjoy Das wrote: > > Hi Hal, > > On Thu, Jan 5, 2017 at 6:12 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel

Right, will fix the CallInst, copy/pasted from a different case and didn't notice what I was doing, thanks. Re LangRef.rst, that's what I meant, I'm still hoping for better suggestions regarding the name... As to the conflict - Tobias, feel free to go first, I'll merge. -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Thursday, July 25, 2013 12:11

On 01/13/2010 02:07 AM, Duncan Sands wrote: > Hi Dustin, the code generators do not support unwind, only the > interpreter does. Ah, the secret is not to even try to frob the gnorts. Manual unwinding, here I come. :-( I was going to say the interpreter doesn't either, but then I recalled it JITs when it can. I don't know how to call into libc from the interpreter to test that.

LLVM today does not clearly specify if a function specified to not write to memory (i.e. readonly or readnone) is allowed to throw exceptions. LangRef is ambiguous on this issue. The normative statement is "[readnone/readonly functions] cannot unwind exceptions by calling the C++ exception throwing methods" which does not decide an answer for non C++ languages. It used to say (h/t

Hi Andrew, On 22/07/13 10:23, Andrew Trick wrote: > > On Jul 22, 2013, at 12:56 AM, Duncan Sands <baldrick at free.fr > <mailto: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

This is a proposal to add guard intrinsics to LLVM. Couple of glossary items: when I say "interpreter" I mean "the most conservative tier in the compilation stack" which can be an actual interpreter, a "splat compiler" or even a regular JIT that doesn't make optimistic assumptions. By "bailing out to the interpreter" I mean "side exit" as