search for: setdatalayout

...ions( targetOptions ); TargetMachine *targetMachine = engineBuilder.selectTarget(); assert(targetMachine && "failed to create target machine"); std::cout << targetMachine->createDataLayout().getStringRepresentation() << "\n"; Mod.get()->setDataLayout( targetMachine->createDataLayout().getStringRepresentation() ); // this segfaults Mod.get()->setDataLayout( targetMachine->createDataLayout() ); // as well as this } Backtrace: Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". e-m:e-i64:64-f80:...

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 property of the target, not the program being > compiled. If you don't like structure packing etc, use packed > structure types. Then, Module::setDataLayout should be removed or make it fail on those circu...

...engineBuilder.selectTarget(); >> >> assert(targetMachine && "failed to create target machine"); >> >> std::cout << >> targetMachine->createDataLayout().getStringRepresentation() << "\n"; >> >> Mod.get()->setDataLayout( >> targetMachine->createDataLayout().getStringRepresentation() ); // >> this segfaults >> Mod.get()->setDataLayout( targetMachine->createDataLayout() ); // >> as well as this >> } >> >> >> Backtrace: >> >> >> Using ho...

...r 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 property of the target, not the program being >> compiled. If you don't like structure packing etc, use packed >> structure types. > > Then, Module::setDataLayout should be rem...

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?

...gine * ee = builder.         setErrorStr( &errStr ).         setEngineKind( llvm::EngineKind::JIT ).         setTargetOptions( topts ).         create(builder.selectTarget( llvm::Triple(llvm::Triple::normalize(platform::target->triple)), "", "", mattrs ));     module->setDataLayout( ee->getDataLayout() ); Where `module` is my `llvm::Module` with the generated IR code. I'm using the triple `x86_64-pc-linux-gnu`, the same as clang on the machine, but getting different alignments. I'm assuming the above is somehow not creating the correct layout. Perhaps there's...

...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 > `setDataLayout`. > > > On 19/04/18 10:44, edA-qa mort-ora-y via llvm-dev wrote: > > 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. > &gt...

...s: >> >>> 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 etc, use packed >>> structure types. >> >> Then, Mod...

...eroperate 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 noted that what the user sets through Module::setDataLayout is simply ignored. LLVM uses the data layout required by the native C ABI, which is hardcoded into LLVM's source code. So I asked: pass the value setted by Module::setDataLayout to the layers that are interested on it, as any user would expect. The response I got was, in essence, "As you a...

...e 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 `setDataLayout`. On 19/04/18 10:44, edA-qa mort-ora-y via llvm-dev wrote: > 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 l...

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 data layout > required by the native C ABI, which is hardcoded into LLVM's source &...

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 etc, use packed structure types. -Chris

...s > able to fix this problem automatically, but why does llvm-gcc output > i64:32:64 rather than i64:64:64? FYI: the X86 data layout is hard-coded in lib/Target/X86/X86TargetMachine.cpp, so that assert is mostly bogus, and the existence of "target datalayout" IR setting and Module::setDataLayout are deceiving.

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 target without having to be linked > to a target backend. Well, it is used by one layer, ignored by another. Anyways LLVM is not doing what the u...

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 be linked >> to a target backend. > > Well, it is used by one layer, ignored by another. Anyways LLV...

Hi All, I have a C code: ////////////////////////////// #include "stdio.h" int main () { putchar('a'); return 0; } llvm-gcc -emit-llvm, I got //////////////////////////////////////// ; ModuleID = 't1.bc' 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" target triple

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

On May 27, 2012, at 9:15 PM, Santos Merino wrote: > I have found that the problem is the endianness of Values. For example a 1 it's > stored as 00000001 00000000 00000000 0000000 instead of 0000000 00000000 0000000 > 00000000 so how can I change how the values are stored and/or load (because I > suppose that the problem is when I store it or load from memory) Are you setting up

In my main function after generate the code and before start the execution via JIT I do this: ExecutionEngine *EE = EngineBuilder(M).create(); string str = EE->getTargetData()->getStringRepresentation(); str[0] = 'e'; M->setDataLayout(str); if (verifyModule(*M)) { errs() << argv[0] << ": Error building the function!\n"; return 1; } vector<GenericValue> noargs; GenericValue GV = EE->runFunction(Main, noargs); outs() << "Result: " << GV.IntVa...

...In my main function after generate the code and before start the execution > via > JIT I do this: > > ExecutionEngine *EE = EngineBuilder(M).create(); > string str = > EE->getTargetData()->getStringRepresentation(); > str[0] = 'e'; > M->setDataLayout(str); > > if (verifyModule(*M)) { > errs() << argv[0] << ": Error building the function!\n"; > return 1; > } > > vector<GenericValue> noargs; > GenericValue GV = EE->runFunction(Main, noargs); > > outs() <&lt...