search for: billtohara

...do it programmatically, I think you might be > stuck.  IIRC the length known by the JIT memory allocator is an > overestimate (it's rounded up for alignment), so the disassembler will > hit garbage at the end. > > Reid > > On Tue, Jul 6, 2010 at 3:07 PM, Bill O'Hara <billtohara at gmail.com> wrote: >> Hi, >> >> With the new llvm-mc code for disassembling, what is the recommended >> way to disassemble the final code produced by a JIT compiler backend? >> (Eg. in the toy.cpp example from the tutorial). >> >> I can get the void* f...

...dCode.html If you still want to do it programmatically, I think you might be stuck. IIRC the length known by the JIT memory allocator is an overestimate (it's rounded up for alignment), so the disassembler will hit garbage at the end. Reid On Tue, Jul 6, 2010 at 3:07 PM, Bill O'Hara <billtohara at gmail.com> wrote: > Hi, > > With the new llvm-mc code for disassembling, what is the recommended > way to disassemble the final code produced by a JIT compiler backend? > (Eg. in the toy.cpp example from the tutorial). > > I can get the void* for the final code, but I don...

Hi, With the new llvm-mc code for disassembling, what is the recommended way to disassemble the final code produced by a JIT compiler backend? (Eg. in the toy.cpp example from the tutorial). I can get the void* for the final code, but I don't know its length - superficially at least it appears I need to know the length to disassemble it as a buffer? Thanks b.

...k you might be >> stuck. IIRC the length known by the JIT memory allocator is an >> overestimate (it's rounded up for alignment), so the disassembler will >> hit garbage at the end. >> >> Reid >> >> On Tue, Jul 6, 2010 at 3:07 PM, Bill O'Hara <billtohara at gmail.com> wrote: >>> Hi, >>> >>> With the new llvm-mc code for disassembling, what is the recommended >>> way to disassemble the final code produced by a JIT compiler backend? >>> (Eg. in the toy.cpp example from the tutorial). >>> >...

...; stuck.  IIRC the length known by the JIT memory allocator is an >>> overestimate (it's rounded up for alignment), so the disassembler will >>> hit garbage at the end. >>> >>> Reid >>> >>> On Tue, Jul 6, 2010 at 3:07 PM, Bill O'Hara <billtohara at gmail.com> wrote: >>>> Hi, >>>> >>>> With the new llvm-mc code for disassembling, what is the recommended >>>> way to disassemble the final code produced by a JIT compiler backend? >>>> (Eg. in the toy.cpp example from the tutorial)....

"Bill O'Hara" <billtohara at gmail.com> writes: > 1>LLVMX86CodeGen.lib(X86JITInfo.obj) : error LNK2019: unresolved > external symbol X86CompilationCallback referenced in function "public: > virtual void (__cdecl*__cdecl > llvm::X86JITInfo::getLazyResolverFunction(void * (__cdecl*)(void > *)))(void...

Hi, I have my simple jit'd language working to my satisfaction. Next, I'd like to add the ability to compile to standard ELF executables on Linux (and whatever is appropriate on the other platforms). Rather than printing assembly language to files and invoking the assembler and linker, is there a fast way I can convert my JIT to a static compiler? Thanks b.

Hi Can anyone provide insight on the current status of the AVX support in LLVM 2.8? I gather from the release notes that the MC assembler supports it, and clang added support for it. Does clang support mean intrinsics only, or is there support for lowering of some sort of gcc vector extension? If I generate llvm vector instructions, is there support to emit 128 or 256b AVX instructions assuming

Hello, Following some recent messages about building with Visual Studio 2010, I have gotten most things to compile in release mode on 64b windows 7. (Mainly the few errors with 0 -> nullptr in the second argument of the pair constructor, and making an ECValue constructor public). I'm falling at the last hurdle though when it comes to the final link: 1>------ Build started: Project:

To disassemble jit code I typically use the udis86 support. Are there patches floating around to support SSE4.1 and SSE4.2 in this? I'd like to use it on a nehalem based machine and investigate the llvm code generation for SSE4.2 in a jit context. thanks bill -------------- next part -------------- An HTML attachment was scrubbed... URL:

Can anyone comment on how they are approaching profiling of jitted code in their llvm backends? For linux and windows, I'm wondering which tools are best integrated with (be it gprof or callgrind on linux, or vtune on either platform). Thanks b.