similar to: [LLVMdev] Function inlining and JIT

On Aug 28, 2012, at 4:28 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > My JIT compiler builds the optimization passes with code directly > copypasted from `opt'. Indeed, the code is optimized as required, except > from function inlining. If the LLVM assembler code emitted by my JIT > compiler is passed through `opt' with -O2 or higher, small functions are > inlined

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: >> If I activate the Inliner pass: >> >>    Builder.Inliner = createFunctionInliningPass(Threshold); >> >> this is the result: >> >> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >> >> It happens on almost all my test

Óscar Fuentes <ofv at wanadoo.es> writes: >>> If I activate the Inliner pass: >>> >>>    Builder.Inliner = createFunctionInliningPass(Threshold); >>> >>> this is the result: >>> >>> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >>> >>> It happens on almost

Hi. IIRC some time ago there was some discussion about saving the executable code produced by the JIT to a file, for loading it at the next session. This would require to stream out the executable code before externals are resolved and resolve them when the code is loaded. AFAIK, LLVM does not support this at the moment. What's the difficulty of implementing this feature, on terms of

If I activate the Inliner pass: Builder.Inliner = createFunctionInliningPass(Threshold); this is the result: LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! It happens on almost all my test cases, even at -O0. This JIT compiler does the same as `opt' wrt optimization passes. I'm using a LLVM snapshot from approx 4 months ago.

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>: > Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > >> Yeah that's the two different ones I mean. Everything MS (intrinsics, >> language features etc...) is purely version-bound, so I don't even get >> why CMake insists on checking every known function prototype of for >> example "recv"

Duncan Sands <baldrick at free.fr> writes: >> But you put me on the right track. The problem is that the class is >> returned on the stack. Correction: The class is returned on the FP stack: >> 0x6e08b5b5 <_ZN3Foo6GetFooEv+17>: fldl -0x8(%ebp) >> 0x6e08b5b8 <_ZN3Foo6GetFooEv+20>: leave >> 0x6e08b5b9 <_ZN3Foo6GetFooEv+21>:

Óscar Fuentes <ofv at wanadoo.es> writes: > A good measure of how fast a set of Makefile are is to run the build > with all targets up-to-date. Both builds takes a few seconds (3 or so) > on my Linux quad core box. Whatever improvement can be achieved on this > seems pretty insignifant. Oh, it's significant. When I build the Cray compiler with only non-LLVM stuff changed,

Eli Friedman <eli.friedman at gmail.com> writes: > On Wed, Aug 26, 2009 at 1:10 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> While compiling some sources, translating from my compiler's IR to LLVM >> using the C++ API requires 2.5 seconds. If the resulting LLVM module is >> dumped as LLVM assembler, the file is 240,000 lines long. Generating >> LLVM

On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> Also, now msvc support multiple target. So it's better to set it as >> ${LLVM_ALL_TARGETS} >> It's can working, why not set it to:. > > I think most LLVM users on Windows are interested on X86 only. This > saves a lot of time on the build process and creates smaller >

While compiling some sources, translating from my compiler's IR to LLVM using the C++ API requires 2.5 seconds. If the resulting LLVM module is dumped as LLVM assembler, the file is 240,000 lines long. Generating LLVM code is fast. However, generating the native code is quite slow: 33 seconds. I force native code generation calling ExecutionEngine::getPointerToFunction for each function on

----- Original Message ----- > From: "Tom Stellard" <tom at stellard.net> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, "Óscar Fuentes" <ofv at wanadoo.es> > Sent: Wednesday, December 18, 2013 10:55:43 AM > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze > > On Fri, Dec

Did you specify "--program-prefix=llvm-" on your configure line? That's what tells the llvm-gcc build to use the llvm-* names for the executables. -Jim On Dec 21, 2010, at 7:27 PM, akramul azim wrote: > Thanks a lot both of you. Using --enable-bindings=none, I could build and install LLVM 2.8 and gcc-4.2-2.8 source. However, in the bin directory, I get c++.exe, cpp.exe,

greened at obbligato.org (David A. Greene) writes: > Óscar Fuentes <ofv at wanadoo.es> writes: > >> A good measure of how fast a set of Makefile are is to run the build >> with all targets up-to-date. Both builds takes a few seconds (3 or so) >> on my Linux quad core box. Whatever improvement can be achieved on this >> seems pretty insignifant. > > Oh,

2009/9/12 Reid Kleckner <rnk at mit.edu>: > It's not clear how valuable the feature is if users start to do things > like inlining pointers to heap allocated objects with guards as > optimizations. or what about register variables, or objects half as registers half in memory, or optimizations that exists on one machine (presence of FPU, MMU, etc) and not on others, byte sex,

Whoops, phone rang and I forgot to cc to the list before I typed the message. ----- Forwarded Message ---- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Ruben Van Boxem <vanboxem.ruben at gmail.com> > Sent: Wed, January 5, 2011 3:38:21 PM > Subject: Re: [LLVMdev] include/Config/config.h discrepancies between CMake and >autofoo builds > > > >

Óscar Fuentes <ofv at wanadoo.es> writes: > BTW, -fpcc-struct-return solves the case that motivated this thread. -fpcc-struct-return is an ABI change, hence it requires "compiling the world". Not acceptable. I'll be interested on hearing ideas about how to determine how a function returns a small struct, without knowing the internals of the struct. -- Oscar

Óscar Fuentes <ofv at wanadoo.es> writes: > Okay, we can get rid of recursive make. However, as pointed out > elsewhere, removing recursive make will not make a difference on the > LLVM build. What David Greene says probably is related to difference > sizes among his compiler and LLVM. Ok, whatever. I'm done arguing experiences. -Dave

Mason Wheeler <masonwheeler at yahoo.com> writes: >>If the following statement is true, then which build system to choose >>is a no-brainer: > >>> cmake, while ugly, can be made to support all of our use cases. There >>> are some use cases that autoconf+make can't support >>-- Chandler Carruth, On 21 Jun 2012, at 01:19 > > Unfortunately, >

On Wed, Dec 18, 2013 at 10:57:58AM -0600, Hal Finkel wrote: > ----- Original Message ----- > > From: "Tom Stellard" <tom at stellard.net> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, "Óscar Fuentes" <ofv at wanadoo.es> > > Sent: Wednesday, December 18, 2013 10:55:43 AM