similar to: [LLVMdev] Data layout hard coded for X86 target

Chris Lattner <clattner at apple.com> writes: > On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: > >> In X86Subtarget.h there is a method `getDataLayout' which selects the >> data layout depending on the platform, ignoring whatever the user setted >> with Module::setDataLayout. >> >> What's the rationale for this? > > Data layout is a

On Jul 5, 2010, at 3:31 AM, Óscar Fuentes wrote: > Chris Lattner <clattner at apple.com> writes: > >> On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: >> >>> In X86Subtarget.h there is a method `getDataLayout' which selects the >>> data layout depending on the platform, ignoring whatever the user setted >>> with Module::setDataLayout.

On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: > In X86Subtarget.h there is a method `getDataLayout' which selects the > data layout depending on the platform, ignoring whatever the user setted > with Module::setDataLayout. > > What's the rationale for this? Data layout is a property of the target, not the program being compiled. If you don't like structure packing

Chris Lattner <clattner at apple.com> writes: > On Jul 5, 2010, at 3:31 AM, Óscar Fuentes wrote: > >> Chris Lattner <clattner at apple.com> writes: >> >>> On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: >>> >>>> In X86Subtarget.h there is a method `getDataLayout' which selects the >>>> data layout depending on the

On Jul 5, 2010, at 10:24 AM, Óscar Fuentes wrote: >> I'm not opposed to having it fail when something semantic (like the >> alignment of double) is wrong. The hints like the 'native integer >> types' should not cause it to fail. > > Then I guess that the information provided by the user through > Module::setDataLayout is used in some places instead of the

I don't know if I'm setting the triple of my execution engine correctly.  This is leading to an issue where a struct `{i8,i64}` is not getting the same layout as the ABI expects. I setup my engine/module like this:      llvm::SmallVector<std::string,2> mattrs;      llvm::EngineBuilder builder{ unique_ptr<llvm::Module>(module) };      llvm::ExecutionEngine * ee = builder.    

Does this fix it? Index: lib/Target/X86/X86Subtarget.h =================================================================== --- lib/Target/X86/X86Subtarget.h (revision 48879) +++ lib/Target/X86/X86Subtarget.h (working copy) @@ -144,9 +144,12 @@ std::string getDataLayout() const { const char *p; - if (is64Bit()) - p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; -

Probably better to move the discussion to a bug? Evan On Mar 27, 2008, at 9:04 AM, Duncan Sands wrote: > Does this fix it? > > Index: lib/Target/X86/X86Subtarget.h > =================================================================== > --- lib/Target/X86/X86Subtarget.h (revision 48879) > +++ lib/Target/X86/X86Subtarget.h (working copy) > @@ -144,9 +144,12 @@ > >

Taking one step back, I'm not clear I'm even setting the triple/DataLayout on the module correctly:     module = new llvm::Module( "test", *llvm_context );     module->setTargetTriple( platform::target->triple ); Is that enough to create an appropriate DataLayout for the module?  I don't see anyway to convert a triple to a DataLayout, so I can't call

Hi edaqa, You might need to set your TargetOptions before calling selectTarget. E.g. builder.setTargetOptions(Opts).selectTarget(...); Or you could just let EngineBuilder call selectTarget for you (which is what the no-argument version of EngineBuilder::create does): llvm::ExecutionEngine * ee = builder. setErrorStr( &errStr ). setEngineKind( llvm::EngineKind::JIT ).

Hi, I want to use a function defined in c(++)-code from code generated by llvm. For this I use ExecutionEngine.addGlobalMapping(). I started with the JIT execution engine and everything worked, then I switched to the interpreter engine and it stopped working, but only if compiled on a Linux system. More precisely it works if I use llvm 3.8.1 + gcc (Linux) + JIT llvm 3.8.0 + mingw-gcc

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

Dan Gohman <gohman at apple.com> writes: Great post, Dan. Some comments follow. [snip] > * Target-specific ABI code. In order to interoperate with native > C ABIs, LLVM requires front-ends to emit target-specific IR. > Pretty much everyone around here has run into this. There are places where compatibility with the native C ABI is taken too far. For instance, time ago I

Jianzhou Zhao <jianzhou at seas.upenn.edu> writes: [snip] > The other question is about > target datalayout = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" > > If I use this string to creat a TargetData object directly, I got an > assertion error: > >

Hi Óscar, > There are places where compatibility with the native C ABI is taken too > far. For instance, time ago I noted that what the user sets through > Module::setDataLayout is simply ignored. it's not ignored, it's used by the IR level optimizers. That way these optimizers can know stuff about the target without having to be linked to a target backend. LLVM uses the

Hello Dan. Duncan Sands <baldrick at free.fr> writes: >> There are places where compatibility with the native C ABI is taken too >> far. For instance, time ago I noted that what the user sets through >> Module::setDataLayout is simply ignored. > > it's not ignored, it's used by the IR level optimizers. That way these > optimizers can know stuff about the

Hi Morten, Something else just occurred to me: can you share your EngineBuilder configuration lines? (http://llvm.org/docs/doxygen/html/classllvm_1_1EngineBuilder.html) In particular - are you explicitly setting the optimization level? The old JIT may have had a different default. - Lang. Sent from my iPad > On Feb 4, 2016, at 10:54 PM, Jim Grosbach via llvm-dev <llvm-dev at

Hi Oscar, >>> There are places where compatibility with the native C ABI is taken too >>> far. For instance, time ago I noted that what the user sets through >>> Module::setDataLayout is simply ignored. >> >> it's not ignored, it's used by the IR level optimizers. That way these >> optimizers can know stuff about the target without having to

Here you go: Starting program: /home/chandlerc/code/compilers/build/llvm-gcc/gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const

Hi all, This is Michael and very happy to share my question here! My question is, is there a way to "extract" a function from Module A and write it into another Module B, and generate two new IR files? IRBuilder seems like a workable way but I have to create instructions one by one. I am new to LLVM so don't know whether it is doable, here is my experimental code: