similar to: [LLVMdev] DataLayout

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 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 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

Hi all, The Language Reference says: "The function of the data layout string may not be what you expect. Notably, this is not a specification from the frontend of what alignment the code generator should use. Instead, if specified, the target data layout is required to match what the ultimate code generator expects. This string is used by the mid-level optimizers to improve code, and this

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

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

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 am doing some preliminary investigation into splicing the Modula-3 compiler front end onto llvm. I have a number of questions and will no doubt have more, but will start by asking for advice on this one. The M3 front end has lowered things farther than the llvm IR expects. Whereas llvm accesses fields/data members of records/structs by field number, M3 has already laid out the format of

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());

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",

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

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

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

I added your suggestion and am using this now llvm::legacy::FunctionPassManager *functionPassManager = new llvm::legacy::FunctionPassManager(Mod); llvm::PassRegistry &registry = *llvm::PassRegistry::getPassRegistry(); initializeScalarOpts(registry); functionPassManager->add( new llvm::TargetLibraryInfoWrapperPass(llvm::TargetLibraryInfoImpl(targetMachine->getTargetTriple())) );

I’ve been debugging SAFECode source code files, and line 170 in ArrayBoundCheckLocal.cpp has been causing the following compilation error: In file included from /Users/peterfinn/Desktop/llvm_trunk_2/projects/safecode/lib/ArrayBoundChecks/ArrayBoundCheckLocal.cpp:18: In file included from

Are you expecting to use a single set of IR files to generate code for multiple targets? Otherwise I'm not sure why your .ll files would necessarily lack the data layout information. The reason I ask is that LLVM IR is fundamentally not target independent in ways far beyond the presence or absence of the data layout string. For gory details:

Hi all, We are developing our own compiler front-end and use LLVM as back-end. We generate .ll files and use opt/llc to generate target specific code. When I generate datalayout information in my .ll file it seems that it enables more optimization from LLVM opt. How can I determine which optimization are driven by datalayout information generation ? In other words, when I don't generate

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Chris Lattner > 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

Hi, I've been debugging this issue for many hours, and would like a sanity check. The issue is that DL (DataLayout) is nullptr inside isDereferenceablePointer() no matter what I try. Why is DataLayout ever nullptr (shouldn't it get defaults?), and what should I do to make it non-nullptr? Thanks. Ram

On 29 January 2014 15:53, Jim Grosbach <grosbach at apple.com> wrote: > Hi Nick, > > The main use case I’ve seen is that it makes writing generic test cases > for ‘opt’ easier in that it’s not necessary to specify a target triple on > the command line or have a data layout in the .ll/.bc file. That is, in my > experience, it’s more for convenience and perhaps historical