similar to: [LLVMdev] LLVMdev Digest, Vol 59, Issue 25

Hi, I'm trying to use exception control by LLVM. In the demo page, I got : declare i8* @llvm.eh.exception() nounwind But, when a try to emit the code by llvm engine, the name is generate with the sufix .132 ( llvm.eh.exception.132 ) and the Function::getIntrinsicID abort the program. It was so : Intrinsic::getDeclaration(llvm_module,Intrinsic::memset,&Tys,1); Now, it's

struct xfirstStru { int var1; double var2; int var3; char *var4; }; %FIRSTSTRU_PLUSPLUS_TOTVS. = type { i32, double, i32, i8* } Hi, I had not applied the layout at run time, only during the emission of the .bc. Now it's running ok when I allocate the structure point at LLVM side, but, when I allocate the structure pointer in the C

1. Re: LLVM optmization (Bill Wendling) Hi, The IR is not wrong. I said that the assembler generated by MSVC is quicker. We can see that the for loop, in the TESTE function, is done without jump's in the MSVC and with jumps in LLVM. I think thats the point. If we don't use threads, the result is the same. My test were done with one billion interactions in the for loop. The MSVC

Hi, It's not ok yet. When a C function calls a LLVM function, or a LLVM function calls a C function, the offset of the variables are wrong. When a don't mix LLVM with C, it's ok, but I need call extern functions using structs. Ciao Manoel Subject: Re: [LLVMdev] Structure alignment To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Message-ID:

%FIRSTSTRU = type { i32, double, i32, i8* } struct { int var1; double var2; int var3; char *var4; }firstStru ; Could someone help? If, running a application in windows with MSVC, I allocate a memmory buffer and call a LLVM function with such buffer, there's a structure alignment problem. If the LLVM function call a C function using the same buffer, it runs fine. Any ideas?

The following C code : #include <stdio.h> #include <stdlib.h> int TESTE2( int parami , int paraml ,double paramd ) { int varx=0,vary; int nI =0; //varx= parami; if( parami > 0 ) { varx = parami; vary = varx + 1; } else { varx = vary + 1; vary = paraml; } varx = varx + parami + paraml; for( nI = 1 ; nI <= paraml; nI++) { varx =

The following C test program was compiled using LLVM with -O3 option and MSVC with /O2. The MSVC one is about 600 times faster than the one compiled with the LLVM. We can see that the for loop in MSVC assembler is solved in the optimization pass more efficiently than that in LLVM. Is there an way to get a optimization result in LLVM like that of the MSVC? Manoel Teixeira #include

I tried to compile LLVM + stdcxx and I got a lot of compiling errors. Did anyone got that? Manoel Teixeira

Is there some preprocess directive to compile LLVM using stdcxx in Windows + MSVC 2005? Manoel Teixeira

Hi, When I try to use va_start(ptr), I got the following problem : Type *Tys = PointerType::get(IntegerType::get(8), 0); return Intrinsic::getDeclaration(llvm_module,Intrinsic::vastart,&Tys,1); ............... The Name generated is "llvm.va_start.p0i8", so, it's not found, abending the process. and Len = 18 In intrinsics.gen : if (Len == 13 && !memcmp(Name,

Hi, When I try to use va_start(ptr), I got the following problem : Type *Tys = Type::VoidTy; Or Type *Tys = PointerType::get(IntegerType::get(8), 0); return Intrinsic::getDeclaration(llvm_module,Intrinsic::vastart,&Tys,1); ............... The Name generated is "llvm.va_start.p0i8", so, it's not found, abending the process. and Len = 18 In intrinsics.gen : if (Len == 13

Hi, I have a problem using structs, when calling a function written in C from a LLVM function or calling a LLVM function from a C one. I noticed that the LLVM align double with 4 bytes and our run time routines use 8, in MS Windows. If a use #pragma pack(4) in my C programs, the routines run fine, but I must ensure that all external call should use the #pragma directive. If I change the llvm

On Aug 4, 2011, at 2:58 PM, Peter Lawrence wrote: > Bill, > I suspect we're talking about two different aspects, > I think you are saying that there is an ability for the DWARF Actions Table > to contain multiple lists, including multiple filter lists - no disagreement > there, > I am saying that for any one landing-pad it might not make sense > for it to be able

On Jul 27, 2011, at 10:27 AM, Peter Lawrence wrote: > 1) it is good to see that the "exception regions" idea has been abandoned, it is mathematically > inconsistent with modern optimization theory, and at best would require extra passes to translate > into/outof that representation form. > Yeah. I didn't want to obscure the main proposal by inappropriate nomenclature.

Hi Bill, Thanks for working on this. Is there a reference for the function attribute uwtable, or is it to be defined as part of this effort? Thanks in advance Garrison On Jul 23, 2011, at 1:29, Bill Wendling wrote: > 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

On Jul 27, 2011, at 10:27 AM, Peter Lawrence wrote: > 3.b) I have been thinking about other possible control-flow-graph invariants of the > landingpad blocks and the catch blocks that they lead to, but so far have not come up > with very muchl, I wonder if anyone else is thinking about this...?... > > for example cleanups come before __cxa_begin_catch, but it isn't clear what

Hi Chris, Function is currently 108 bytes large. Could 4 more bytes really be an issue? Actually 2 should suffice. While I understand that some applications value storage more than anything, many applications value compilation time very highly. getIntrinsicID is called all over the place (isIntrinsic uses it as well), and every single time it checks the function name. To me that sounds a lot

Hi Jeffrey, Please correct me if I'm wrong, but I believe a test that checks for the old behavior would be pointless. I realize that my patch would return an unmatching intrinsicID when the function's name changes, but the real question we should ask is do we really want to be able to change the intrinsicID by changing the function's name? Also, the original Function constructor

Hi John, >> Inlining >> -------- >> >> Many a plausible seeming exception handling scheme has fallen by the way-side >> because it interacts poorly with inlining. >> >> Here is how inlining would work with this scheme. It's pretty close to how >> it works right now. Suppose you have >> >> invoke void @foo() >>

Hi, catch_all.cpp: 1 int main() 2 { 3 try { 4 throw 34; 5 } 6 catch (...) {} 7 } llvm-gcc -O3 -S -emit-llvm catch_all.cpp -o catch_all.ll: 1 ; ModuleID = 'catch_all.cpp' 2 target datalayout =