similar to: [LLVMdev] make DataLayout a mandatory part of Module

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

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

On 02/14/2014 05:55 PM, Philip Reames wrote: > Splitting out a conversation which started in "make DataLayout a > mandatory part of Module" since the topic has decidedly changed. This > also relates to the email "RFC: GEP as canonical form for pointer > addressing" I just sent. > > On 02/10/2014 05:25 PM, Nick Lewycky 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 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 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

On 02/24/2014 12:45 AM, Andrew Trick wrote: > > On Feb 21, 2014, at 10:37 AM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >> >> On 02/14/2014 05:55 PM, Philip Reames wrote: >>> Splitting out a conversation which started in "make DataLayout a >>> mandatory part of Module" since the

On 02/24/2014 11:27 AM, Andrew Trick wrote: > > On Feb 24, 2014, at 11:17 AM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >> >> On 02/24/2014 12:45 AM, Andrew Trick wrote: >>> >>> On Feb 21, 2014, at 10:37 AM, Philip Reames >>> <listmail at philipreames.com <mailto:listmail 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

----- Original Message ----- > From: "Pete Cooper" <peter_cooper at apple.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Sunday, October 19, 2014 3:34:59 PM > Subject: Re: [LLVMdev] RFC: Are we ready to completely move away from the optionality of a

The LLVA and LLVM papers motivate the GetElementPtr instruction by arguing that it abstracts implementation details, in particular pointer size, from the compiler. While it does this fine for pointer addresses, it does not manage it for address offsets. Consider the following code: $ cat test.c int main() { int *x[2]; int **y = &x[1]; return (y - x); } $ llvm-gcc -O3 -c test.c

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

Hi Gordon, > TargetData is a concrete class, part of the middle-end. It describes > parts of the the target's ABI. It allows target-independent passes to > do things like decide whether x[1] and ((char *) x)[4] alias. This is > possible without actually linking with the code generator for the > relevant target. TargetData can be encoded in the LLVM IR, e.g. target

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

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

On 16 Nov 2016, at 21:56, Daniel Berlin <dberlin at dberlin.org> wrote: > > You keep talking about platforms, but llvm ir itself is not platform dependent. > Can you give a reference in the language reference that says that this is not legal? Nothing in the LangRef (apart from the note about non-integral pointers, which was added recently) makes any claim about the representation

Hi, All. Does anybody know about ConstantExpr in llvm? What's it? Since it always appears after llvm optimization such as -O2 level, what is it supposed to be to codegen? I am wondering it represents constant value which can be determined or computed at compile-time(actually is link-time) to improve performance. Although we do not know the actual constant value util the object file is linked.

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: