similar to: [LLVMdev] Why 'target datalayout' strings are in .ll modules?

I tried bu clang seems to support only target on which it has been compiled. If I use: with clang -S -emit-llvm t.c -o t.ll I've got following file for t.ll ; ModuleID = 't.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple =

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

Hi, My compiler emits LLVM IR in text form and passes it to the opt and llc executables. The datalayout and triple are currently determined by running "clang -x c /dev/null -emit-llvm -S -o -" and parsing the output. This works fine because clang seems to choose a generic version of the CPU it is running on, and this is exactly what we want. Still this solution is hacky and

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

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

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

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

Hello, I have the following DataLayout string: e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32 Note that it has f80:128:128 followed by f80:32:32. This is an output from clang on Windows (clang -m32 -emit-llvm). Triple is i686-pc-win32. Documentation doesn't specify the interpretation of such

You can compile an empty C source code with clang -S -emit-llvm and copy the data layout from there. 2011/10/27 Seb <babslachem at gmail.com> > Hi all, > > Can someone give me advice on what should be a good definition of target > datalayout for an ARM cortex-A9 + neon target and x86 32-bit ? > Shall I use a different definition for a cortex-A9 without neon ? > Thanks for

Hi all, Can someone give me advice on what should be a good definition of target datalayout for an ARM cortex-A9 + neon target and x86 32-bit ? Shall I use a different definition for a cortex-A9 without neon ? Thanks for your advices Best Regards Seb -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 30 January 2014 09:55, Philip Reames <listmail at philipreames.com> wrote: > On 1/29/14 3:40 PM, Nick Lewycky 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

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 2015-Jun-01, at 11:06, Reid Kleckner <rnk at google.com> wrote: > > I'm pretty sure module linking is expected to occur in the same LLVM context. Correct. > IIRC Duncan had some proposal for how ld64 could do something clever with multiple contexts, but I've totally forgotten what it was. This was for LTO (probably unrelated to Yuri's scenario?). 1.

Eric Christopher wrote: > How are you trying to call it? Do you have a DataLayout? In test/Analysis/ValueTracking/memory-dereferenceable.ll, just change byval to dereferenceable(8), and %dparam won't match (see lib/IR/Value.cpp:521 for the logic that is supposed to fire). How do I get it to pass? I tried introducing a target-triple and target-datalayout, but it didn't help.

> 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

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

On 02/20/2011 23:50, Duncan Sands wrote: > Hi Yuri, > > >> I get SEGV in gcc-compiled procedure in Solaris10-i386. This procedure >> is called from llvm JIT code. >> Exact instruction that crashes is this: movdqa %xmm0, 0x10(%esp) >> %esp is 8-aligned, and by definition of movdqa it expects 16-aligned stack. >> This leads me to believe that llvm uses

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