similar to: [LLVMdev] DataLayout: Module vs Target

hey, so I'm writing in cpp. the documentation says that TheModule -> getDataLayout should return const DataLayout, but instead it is returning std::string. I require it to return DataLayout, as I generalize my function pass manager to accept the DataLayout constant as an argument, it being the only thing in common amongst both the ExecutionEngine and the Module class. Any pointers to

I think I see a potential issue. My ExecutionEngine setup may not be using the same target as my object code emitting, and in this test case I'm running in the ExecutionEngine.  I'll go over this code to ensure I'm creating the same triple and see if that helps -- I'm assuming it will, since I can't imagine the exact same triple with clang would produce a different layout. On

What exactly is your alignment settings in your LLVM struct? Something like this would tell you the alignment of "something". const llvm::DataLayout dl(theModule); size_t size = dl.getPrefTypeAlignment(something); IIn "my" compiler, I don't do anything special to align structs, so it's plausibly your specific data-layout that says that i64 only needs aligning to

Hi all, We have multiple DataLayout object in flight during a compilation: at least the one owned by the Module and the one owned by the TargetMachine. There are two issues: 1) What if they differ? I guess we could assert at the beginning of CodeGen. 2) The DataLayout has internal mutable state (a cache of StructLayout). The latter is my current concern: the cache in DataLayout is based on Type

On Mon, Oct 20, 2014 at 9:11 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 20, 2014, at 8:22 PM, Eric Christopher <echristo at gmail.com> wrote: > >> On Mon, Oct 20, 2014 at 7:51 PM, Chris Lattner <clattner at apple.com> wrote: >>> Hi Eric, >>> >>> Can you elaborate on your goals and what problem you are trying to solve? As

On Mon, Oct 20, 2014 at 1:27 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, Oct 20, 2014 at 1:18 PM, Eric Christopher <echristo at google.com> > wrote: >> >> Agreed. The DataLayout should move (back) to the TargetMachine and live >> there (I'm doing that part right now). I don't particularly want to put it >> on the module

On Wed Oct 22 2014 at 12:33:53 PM Chris Lattner <clattner at apple.com> wrote: > On Oct 20, 2014, at 10:41 PM, Eric Christopher <echristo at gmail.com> wrote: > >>> So the storage for DataLayout right now is on a per-subtarget basis. > >>> I.e. if you don't construct one in the module the backend will make > >>> one up based on information in

On Mon, Oct 20, 2014 at 7:51 PM, Chris Lattner <clattner at apple.com> wrote: > Hi Eric, > > Can you elaborate on your goals and what problem you are trying to solve? As Chandler points out, DataLayout is part of module for a reason. Which is an interesting point - it's not really. (This was also going to be part of my talk next week, but since it's been brought up...) So

I get a segfault with this code when setting the data layout: int main(int argc, char** argv) { llvm::InitializeNativeTarget(); llvm::LLVMContext TheContext; unique_ptr<Module> Mod(new Module("A",TheContext)); llvm::EngineBuilder engineBuilder(std::move(Mod)); std::string mcjit_error; engineBuilder.setMCPU(llvm::sys::getHostCPUName());

On Mon, Oct 20, 2014 at 9:51 AM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 19, 2014, at 1:22 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > > I've just wasted a day chasing my tail because of subtleties introduced > to handle the optionality of the DataLayout. I would like to never do this > again. =] > > > > We now have

Ok. I can make a copy of the unique_ptr before moving it into the builder's constructor and use the copy later on. It is confusing to require a unique_ptr. Frank On 09/14/2016 12:11 PM, Frank Winter via llvm-dev wrote: > I am constructing the engine builder in the following way: > > llvm::SMDiagnostic Err; > unique_ptr<Module> Mod = getLazyIRFileModule("f.ll",

Hello all, As we work the last few bugs out of our project for the last release, we need to find a way to set the default datalayout of the LLVM Assembly file we are generating to be that of the host machine. I've seen options for target triples in the Doxygen but not the datalayout. BTW, we're using version 2.6 of LLVM. --Sam

I've just wasted a day chasing my tail because of subtleties introduced to handle the optionality of the DataLayout. I would like to never do this again. =] We now have this attached to the Module with just a flimsy faked-up pass to keep APIs consistent. So, is there any problem with beginning down the path of: 1) Synthesizing a "default" boring DataLayout for all modules that

Sorry in advance for the stupid question, i still don’t understand some concepts like passes. I took a piece of code from llc, and I used it to write a function that creates an object (or assembly) file from an IR module. It compiles without any problems. But program crashes when it reaches add() method of the pass manager. Can you help me figuring out what’s the problem please? here is my

The stack trace: llvm::PMTopLevelManager::addImmutablePass(llvm::ImmutablePass*) llvm::PMTopLevelManager::schedulePass(llvm::Pass*) moduleToObjectFile(llvm::Module*,std::string&,llvm::LLVMContext&) Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target > On Mar 24, 2016, at 1:14 AM, Mehdi Amini

Hi everyone, I was happily using MCJIT for over a year until yesterday when I created a function call with an argument of a struct type. That caused a crash in SelectionDAG around DataLayout::getAlignment(). I remember the noise about the DataLayout started being mandatory. But I cannot find precise information. Should I set the DataLayout in every Module created? Where can I get the

Sorry, that's a pure crash I think, assertions are not triggered. Xcode doesn’t map those 2 functions to line numbers because they’re in precompiled libraries On Mar 24, 2016, at 1:44 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Mar 23, 2016, at 5:41 PM, Lorenzo Laneve <lore97drk at icloud.com <mailto:lore97drk at

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

Assuming you are talking about this line: passmanager.add(tliwp); I don't see anything obviously wrong. Are you hitting an assertion or a pure crash? (if LLVM not built with assertions, please rebuild). What does your debugger gives you as a stracktrace? -- Mehdi > On Mar 23, 2016, at 3:44 PM, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sorry in

I’m using LLVM 3.8.0, and no, it’s the precompiled version That’s why it doesn’t give me enough info for debug > On 24 Mar 2016, at 1:53 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > This code path is not likely to crash usually. Did you build LLVM yourself? Which version are you using and can you reduce the test case to be "minimal" so that someone can