similar to: How to get generic datalayout and "target-cpu" attribute

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

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:

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

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

What is the meaning of 'target datalayout' being in .ll in addition to 'target triple'? When it can be meaningfully changed having the same 'target triple'? As I understand llvm derives most of architecture-specific information from 'target triple'. For example ABI used by llvm is keyed to 'target triple'. But some parts of ABI are in 'target

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

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

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.

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

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

LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: * That the pointer size used for the stack is the same size as the code size pointer, which is also the

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

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 like this:      llvm::SmallVector<std::string,2> mattrs;      llvm::EngineBuilder builder{ unique_ptr<llvm::Module>(module) };      llvm::ExecutionEngine * ee = builder.    

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

On 5 February 2014 09:45, Philip Reames <listmail at philipreames.com> wrote: > On 1/31/14 5:23 PM, Nick Lewycky wrote: > > 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

Taking one step back, I'm not clear I'm even setting the triple/DataLayout on the 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

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