similar to: [LLVMdev] Target Data

I see, thanks. However, if I -emit-llvm and then append the "target datalayout" string (then operate on that emitted llvm), I can then change the data type sizes and alignments, correct? Thanks. On Thu, Mar 22, 2012 at 2:25 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 21, 2012, at 5:57 PM, Ryan Taylor wrote: > > > Is it possible to change the

On Mar 21, 2012, at 5:57 PM, Ryan Taylor wrote: > Is it possible to change the widths of types independent of the architecture? Or to reset the widths of types? > > I haven't seen anything like this. Thanks. The datalayout string is required to match the target, if it exists: http://llvm.org/docs/LangRef.html#datalayout You can't control it to change how things are laid out.

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Thu, Mar 22, 2012 at 2:56 PM Subject: Re: [LLVMdev] Target Data To: Chris Lattner <clattner at apple.com> So I read that link yesterday and it says that it uses some default unless they are overridden by the datalayout keyword, which from what I can tell can only be put in an LLVM IR file to be

Micah, can you document this in the release notes? On Wed, Oct 24, 2012 at 4:34 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Oct 24, 2012 at 4:11 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> Has this been removed/replaced? Couldn't find anything in the release notes. > > Renamed DataLayout. > > -Eli >

I would like it to always be lowered, I don't want it. On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com>wrote: > You don't have memcpy or want it to always lower it? > > -eric > > On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > Christoph, > > > > Yes, you are correct on the lifetime

> On Aug 21, 2018, at 17:57, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Matt, > I'm sorry, actually it's fma not fmad. > > In the post-legalizer DAG combine for the given code it's producing fma not fmad. That doens't seem correct. > The contract is on the fadd. I’m not really sure what the rule is supposed to be for contract between the nodes.

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Dec 12, 2011 at 4:58 PM Subject: Re: [LLVMdev] GetElementPtr To: Eli Friedman <eli.friedman at gmail.com> Sorry, So what I'm trying to ask is are the widths given (32, 64) for the index and the offset the widths of the index and offset values or the width of the type they are

Has this been removed/replaced? Couldn't find anything in the release notes. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121024/9aa47f9d/attachment.html>

On 22.08.2018 13:29, Ryan Taylor wrote: > The example starts as SPIR-V with the NoContraction decoration flag on > the fmul. > > I think what you are saying seems valid in that if the user had put the > flag on the fadd instead of the fmul it would not contract and so in > this example the user needs to put the NoContraction on the fadd though > I'm not sure

LGTM for this bit. On Oct 25, 2012 7:52 AM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Here is my patch for it: > Index: ReleaseNotes.html > =================================================================== > --- ReleaseNotes.html (revision 166627) > +++ ReleaseNotes.html (working copy) > @@ -669,6 +669,9 @@ > "TargetTransformInfo"

If what you're trying to do is use LLVM as a target-independent bitcode representation, you should be aware that it's not made for that purpose. In fact, it's specifically *not* target-independent, no matter what the types are. For you initial question, you cannot map back from LLVM IR to C types, because the two have little to do with each other. -bw On Apr 16, 2012, at 2:43 PM,

I don't think the global fast math flag should override the NoContraction decoration as that's mostly the point of that decoration to begin with, to have fine granular control while still having a broad sweeping optimization. Did I miss your point? I feel like I did. On Thu, Aug 23, 2018, 3:42 PM Michael Berg <michael_c_berg at apple.com> wrote: > Ryan, > > Given that the

How do you determine if a shift is signed or not? ashr = always signed? lshr = always unsigned? shl = always signed? The CmpInst has the "isSigned()" function, but it appears that every other Instruction I've looked at doesn't seem to have this. -------------- next part -------------- An HTML attachment was scrubbed... URL:

So in this example: %idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1 Why is it picking i64 for the index but i32 for the offset? On Mon, Dec 12, 2011 at 4:58 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Ryan Taylor <ryta1203 at gmail.com> > Date: Mon, Dec 12, 2011 at 4:58 PM > Subject: Re:

LLVMers, I have a const StructType *StTy where I call TargetData->getStructLayout(const_cast<StructType*>(StTy))->getSizeInBits() but it continues to return 64 regardless of the actual size of the struct? I want the size of the structure in bits, including alignment padding for offset calculations, is this not the right function call? Thanks. -------------- next part

On Nov 4, 2019, at 4:00 PM, James Molloy via llvm-dev <llvm-dev at lists.llvm.org> wrote: > We'd be keen to help out what the community decides to do here. I personally feel it's reasonable that: > - LangRef/DataLayout is updated with semantically coherent changes. > - The midend optimizer is updated by someone who cares about those changes and tests are added that use

Johannes, Thanks, I have been following along some of the thread(s) and the phab reviews. The scope of this work is more encompassing than our current needs and I've looked at trying to carve a piece out. It's not clear to me what purpose the llvm.noalias intrinsic serves right now. Also, if a mem instruction has !noalias metadata, then it should not be aliased, but I must be missing

Clang is inserting an llvm.memcpy function call into my program where it does not exist (the code never calls memcpy), is there a particular reason for this? It also looks like it's inserting two other artificial function calls, something to do with llvm.lifetime.start and llvm.lifetime.end, what are these functions and why are they being inserted artificially? Thanks. -------------- next

On Wed, Oct 24, 2012 at 4:11 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Has this been removed/replaced? Couldn't find anything in the release notes. Renamed DataLayout. -Eli

Here is my patch for it: Index: ReleaseNotes.html =================================================================== --- ReleaseNotes.html (revision 166627) +++ ReleaseNotes.html (working copy) @@ -669,6 +669,9 @@ "TargetTransformInfo" provides a number of low-level interfaces. LSR and LowerInvoke already use the new interface. </p> +<p> The TargetData structure