search for: datalayouts

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

The LLVM Module has an optional target triple and target datalayout. Without them, an llvm::DataLayout can't be constructed with meaningful data. The benefit to making them optional is to permit optimization that would work across all possible DataLayouts, then allow us to commit to a particular one at a later point in time, thereby performing more optimization in advance. This feature is not being used. Instead, every user of LLVM IR in a portability system defines one or more standardized datalayouts for their platform, and shims to place calls w...

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

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

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: den 13 juli 2017 16:01 > To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>; David Chisnall > <David.Chisnall at cl.cam.ac.uk>; Dylan McKay <me at dylanmckay.io> > Cc: llvm-dev at lists.llvm.org; Carl Peto <carl.peto at me.com> > Subject: Re: [llvm-dev] RFC:

My experience of having the address space for functions (or function pointers) in the DataLayout i that when the .ll file is parsed we need to parse the DataLayout before any function declarations. That is needed because we want to attribute the functions with correct address space (according to DataLayout) when inserting them in the symbol table. An alternative would be to update address space

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

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

Hi, I am begineer to llvm, implementing a main.cpp from https://github.com/davidar/lljvm/blob/master/backend/main.cpp A) : When I am declaring a command: * PassManager PM* * PM.add(new DataLayout td)* It shows error: > *error: missing template arguments before ‘PM’* * PassManager PM;* ^ >*main_test.cpp:48:2: error: ‘PM’ was not declared in this scope* *

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

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

Hi Philip, I also tried that including file: #include "llvm/IR/LegacyPassManager.h" but error remain same. Please help. On Tue, Aug 14, 2018, 2:58 AM Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > Hi Ratnesh, > > the PassManager used in that example has moved into the legacy namespace: > http://llvm.org/doxygen/classllvm_1_1legacy_1_1PassManager.html > >

...one data layout was a "subset" of the other (one is missing details of the vector types, for example, in a module that used no vector types), but even that seems tenuous. -Hal >). I can think of a bunch of ways it could fail with > struct layouts of the same struct on different DataLayouts. > > Pete > > > > If there isn't, I'm willing to do some of the leg work here. > > -Chandler > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >...

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

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

...google.com> wrote: > > > The LLVM Module has an optional target triple and target datalayout. > Without them, an llvm::DataLayout can't be constructed with meaningful > data. The benefit to making them optional is to permit optimization that > would work across all possible DataLayouts, then allow us to commit to a > particular one at a later point in time, thereby performing more > optimization in advance. > > > > This feature is not being used. Instead, every user of LLVM IR in a > portability system defines one or more standardized datalayouts for their &g...

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:

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

> 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