similar to: [LLVMdev] Throwing function being marked nounwind under optimzation?

It would help if you post the -O0 and -O1bitcode files. Does it reproduce with opt -O1? If so, use -debug-pass= to figure out when things started going wrong. Does it make sense to compare the bitcode against code generated for x86 target? Evan On Aug 16, 2009, at 11:46 AM, Jim Grosbach wrote: > All, > > The following relatively simple function is behaving oddly under SJLJ >

Dear Community, I have a problem I am trying to code in R. Suppose there are 7 products and each have a ROI value attached to it. There are 400 representatives who calls 150,000 customers with these product detailing and achieve sales through the calls. There is a cost per call and revenue earned from the call. Constraint is revenue should be greater than the cost. Now there can be at most 7

Hello everyone! I've recently had a chance to familiarize myself with the nitty-gritty details of LLVM IR. It has been a great learning experience, sometimes frustrating or confusing but mostly rewarding. There are a few cases I've come across which seems odd to me. I've tried to cross reference with the language specification and the source code to the best of my abilities, but

Hello Sean, Thank you for your reply. I'll give your suggestion to item 6 and 7 a try tonight. I'll start a compilation and let it run throughout the night. My laptop (x61s) is 8 years old by know, so compiling LLVM takes a little time :) Regarding item 8. I don't know if anyone is using "": in the wild so fixing the implementation might make sense. If not the

I am trying to optimize a nested function using nlminb. This throws out an error that y is missing. Can someone help me with the correct syntax?? Thank you. test1 <- function(x,y) { sum <- x + y return(sum) } test2 <- function(x,y) { sum <- test1(x,y) sumSq <- sum*sum return(sumSq) } nlminb(start = c(1,1), test2,lower = c(0,0), upper = c(5,5)) -- View this message in

Hi, Simple description of the problem below. I have code coming into pruneEH as follows fn a { entry: call fn b ... for_cond: %i = phi [1, entry] [%x, for_body] cmp $i with someval cond-br for_body or for_exit for_body: ... $x = $i + 1 branch for_cond for_exit ... } PruneEH determines that the call to fn-b won't return. The code is modified thus. fn a { entry: call fn b unreachable insn

On 07/12/2010 00:23, Duncan Sands wrote: > IIRC, __cxa_end_catch may throw an exception because it runs the destructor > for the exception object, which can execute arbitrary user code and thus may > throw an exception. This is why it is sometimes correct to use invoke for it. > However in the case of your example it seems that llvm-gcc didn't optimize the > code as well as it

On Wed, Jan 28, 2015 at 6:28 PM, Robin Eklind <carl.eklind at myport.ac.uk> wrote: > Hello Sean, > > Thank you for your reply. I'll give your suggestion to item 6 and 7 a try > tonight. I'll start a compilation and let it run throughout the night. My > laptop (x61s) is 8 years old by know, so compiling LLVM takes a little time > :) > This is why I did so much

I have the following C source: extern unsigned int donut; void f1(); void f2(); void f1() { unsigned int *magic = &donut; if (*magic != 286529877) { f2(); } } void f2() { /* Loop here forever if application is built with wrong version of ROM image */ while(1) { ; } } The -O2 level PruneEH pass uses SimplifyFunction() which contains this code: for

On Dec 12, 2007, at 11:01 AM, Duncan Sands wrote: > Hi Dale, > >> No, I don't want to change the semantics of invoke, at least I don't >> think so. >> When inlining, I want the inlined throw to reach cleanup code as it >> does. >> But I want the Unwind_Resume call that ends the cleanup code to be >> replaced with a control transfer to the handler

On 07/12/2010 12:41, John McCall wrote: > For your test case, clang++'s code is correct (and better) because > __cxa_end_catch won't throw for a caught exception of that type. That > said, Which type? There are two pending exceptions at the moment when __cxa_end_catch is called, both with invisible destructors: E* and unknown type thrown from mycatching(). __cxa_end_catch

Hello Anton, While we have been discussing this, my partner discovered the source of where the sj/lj stuff is coming from. Does this mean that the LLVM libraries we're using are broken? Type.cpp ..\..\..\..\llvm\lib/libLLVMCore.a(Type.cpp.obj):Type.cpp.text+0x722): undefined reference to `__gxx_personality_sj0' ..\..\..\..\llvm\lib/libLLVMCore.a(Type.cpp.obj):Type.cpp.text+0x750):

When I compile a piece of C++ with exceptions into .ll I see that gcc frontend in some cases calls __cxa_end_catch with 'call' and in other cases with 'invoke' with termination in case of exception. clang++ always just calls __cxa_end_catch with 'call' instruction. Which way is correct? --- c.cpp --- #include <stdio.h> #include <stdlib.h> struct C {

Dmitry, > This is probably a question for Fortran/DragonEGG experts: > > Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* > @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ? Why it needs > bitcast? Just a wild guess (basing from my llvm-gcc knwoledge though): there is a bug with in gcc fortran frontend where it fails to

Hi Anton, >> How do you think what would be the best way to workaround this problem, if >> it seems to be not in focus for anybody for now? > Keep in mind, this not LLVM problem, it's gfortran problem. Also, it's > of pretty low priority for gcc devs since they do almost no type > checking on TREEs, so the varargs decl seems to be only viable > llvm-side fix.

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

> Oh, right, now I remember: it's a very old problem I knew 1.5 years ago. > There were even some bugs on it, here is a common case: Yes, this is right, fortran frontend produces bogus trees for every external call. The problem seems to have roots from the fact that there is no external function decl here, so frontend has no way even to infer the type from. > How do you think what

Hi Anton, On 17/07/12 15:35, Anton Korobeynikov wrote: >> actually there is a different fix, which is to not pay any attention to GCC >> function types when generating calls (and function prototypes), and instead >> do everything by querying GCC's CUMULATIVE_ARGS. > I tried to do this during llvm-gcc times and it turned out that there > might be different calls with

Thanks, Duncan, makes sense! I suppose you meant something like this: Function* callee = dyn_cast<Function>( call->getCalledValue()->stripPointerCasts()); if (!callee) continue; - D. 2012/7/17 Duncan Sands <baldrick at free.fr> > Hi Dmitry, it would be neater to use stripPointerCasts. > > Ciao, Duncan.

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