similar to: [LLVMdev] Get LLVM assembler for a function.

On Wed, Aug 19, 2009 at 10:30 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > We can get the llvm assembler for a Module with something as simple as > >      std::ofstream f("code.llvm"); >      f << *M; > > Is there a method for obtaining the llvm assembler of a given Function? I think something like "F->print(f);" will do the right thing. -Eli

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: >> Is there a method for obtaining the llvm assembler of a given Function? > > I think something like "F->print(f);" will do the right thing. Nope. It prints nothing at all. mainF->print(std::cout); -- Óscar

On Aug 19, 2009, at 10:30 PM, Óscar Fuentes wrote: > We can get the llvm assembler for a Module with something as simple as > > std::ofstream f("code.llvm"); > f << *M; > > Is there a method for obtaining the llvm assembler of a given > Function? In addition to the other answers, f << *F works too. Dan

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

It seems that support for dumping text representation of LLVM objects to standard channels and C++ output streams was removed. My guess is that now we must use errs() instead of std::cerr, llvm::raw_fd_ostream instead of std::ofstream, etc. The changes are not trivial, as for instance llvm::raw_fd_ostream without flags fails if the file exists, but std::ofstream does not. The changes include

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

Eli Friedman <eli.friedman at gmail.com> writes: > I think something like "F->print(f);" will do the right thing. BTW, what's the reason for `print' and `dump' not being listed on the doxygen page of Function? -- Óscar

On Tue, Aug 25, 2009 at 4:58 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > 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

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

Eli Friedman <eli.friedman at gmail.com> writes: > On Tue, Aug 25, 2009 at 4:58 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> 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

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 >

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 code is fast. > > However, generating the native code is quite slow: 33

Eli Friedman <eli.friedman at gmail.com> writes: > On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> 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 >> executables. Anyways, it they want all targets, it is simply a matter of >> passing

Ó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

On Sun, Aug 9, 2009 at 1:04 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > Eli Friedman <eli.friedman at gmail.com> writes: > >> On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >>> 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 >>>

Let's go directly to the example struct S { double dummy1; double dummy2; }; S bar(); S foo() { return bar(); } This is the result of g++ -c -S -O2 (focus on the final `ret'): __Z3foov: LFB0: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: pushl %ebx LCFI2: subl $20, %esp LCFI3: movl 8(%ebp), %ebx movl %ebx, (%esp) call __Z3barv pushl %eax movl %ebx, %eax movl -4(%ebp), %ebx

On Fri, Sep 25, 2009 at 2:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > I filed a bug yesterday ( http://llvm.org/bugs/show_bug.cgi?id=5046 ) > and Anton kindly explained that LLVM is doing the right thing as per the > ABI (the GCC ABI, I'll add). > >  1. Is there a LLVM way of dealing with this without using separate code >  for VC++ and GCC? I'm not sure what

Hi all, I'd like to be able to write JIT-compiled code to a Windows DLL. I have no idea where to start though. Does LLVM already offer some support for this? Or would it be straightforward to write my own DLL writer (no advanced features needed)? Or maybe I could use an external linker? All help highly appreciated! Cheers, Nicolas -------------- next part -------------- An HTML

Eli Friedman <eli.friedman at gmail.com> writes: > MSVC *is* continuously checked; see > http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9. Anyone > who breaks the MSVC build will get a nastygram from buildbot. This is new news for me. If the developer who broke the msvc build receives a nastygram, would he urged to fix it when he has no msvc compiler and probably no

On Sun, Aug 9, 2009 at 3:35 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > Eli Friedman <eli.friedman at gmail.com> writes: > >> MSVC *is* continuously checked; see >> http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9.  Anyone >> who breaks the MSVC build will get a nastygram from buildbot. > > This is new news for me. > > If the developer