similar to: help me understand how nounwind attribute on functions works?

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

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

Hello Everyone, This is my first attempt to getting used with the submission process. Trying to get the "good practice" with the coding standard, tools, mailing lists... and already a few questions: - Is it possible to "link" 2 related entries in Phabricator ? one for LLVM and one for CFE ? what's the best way of posting 2 related or dependent patches ? - I'd

On Thu, Feb 9, 2017 at 8:41 AM, 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()

Logan, I need to make a correction of the post that preceded this one! I was wrong when I said this: > When I load the bitcode file for this module and then dump it just before it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its work even though it’s not listed above in the list of function pass managers? The “uwtable” attribute does not disappear! I had

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

I observed about +6% performance improvement in one of c++ tests in spec2006 in AArch64 by avoiding inlining functions in exception handling region. I guess this is not really rare because programers often make small methods with throw statement like fCallee() in below sample c++ code. Thanks, Jun > Hi Jun, > > It's a very common that C++ exception handling code blow up the

Hi Christian, Thanks for your explanation. I know your situation now. I would suggest you to check the optimization pass used by the JIT compiler, especially IPO/PruneEH.cpp. It will try to add nounwind attribute to functions which will result in the problem you have mentioned earlier. Alternatively, as a workaround, try to add uwtable (function attribute) to the functions that are generated

This is the only thing that I’ve found that works in terms of getting the exception to propagate out of the JITted function - change the “call” to an “invoke” and hook in the do-nothing landing-pad. https://gist.github.com/drmeister/7a35046f666826206973 Compare line 646 of the file above to the one that I just posted. > https://gist.github.com/drmeister/b97dec956c6ee9ffeb75 The first one

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 everyone, 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 of the function or call

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

Hello! This is my first post here. I came across the very same problem. It can be reproduced within modified tests/Embedding/RParseEval.c Actually this example has another issue, namely it doesn't wrap everything in R_ToplevelExec . This is a major show stopper for newcomers as that function is barely mentioned anywhere and longjmp into terminated setuploop function followed by R_suicide

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

Hi Dmitry, > Do you think this is a system problem of gcc applicable to other functions too, or just a flush-specific bug? it has nothing to do with flush - for all I know flush is fine. Dragonegg does this for all Fortran functions because the Fortran front-end is so buggy, i.e. often produces wrong function types. I have another way of handling this in mind, which would avoid this trick,

Logan, How would I dump the object file generated by the JIT compiler pipeline? Could you point me to an example of how something like that is done? I’m used to working with the JIT machinery in memory but not writing object files out to disk. I’m have code to generate object files for AOT compilation - is it done the same way? Best, .Chris. On Apr 12, 2015, at 2:27 PM, Logan Chien

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

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

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