similar to: [LLVMdev] TargetData class?

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

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 >

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"

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

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

By LLVM do you mean the backend? I'm not using the backend, so is that i32 on the 0 index the type of the index value or the type of the value to which exists at that index? it seems the pointer itself has no width, it's arbitrary and is handled in the lowering and is target dependent on the bus width. Basically, when I am computing offset I need to know the sizes for add. The size of

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:

Ok, thanks, this makes sense. But there is no way to get the SelectionDAG to do it for me via something like visitGetElementrPtr? On Thu, Dec 8, 2011 at 2:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Thu, Dec 8, 2011 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> > >> Thanks. > >> > >> So basically then this

Eli, Ok, thanks, this is a big help. So how can I use the TargetData (or get the TargetData) without having a DAG? On Thu, Dec 8, 2011 at 3:45 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Dec 8, 2011 at 3:29 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Ok, thanks, this makes sense. But there is no way to get the > SelectionDAG to > > do it

On Thu, Dec 8, 2011 at 3:29 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ok, thanks, this makes sense. But there is no way to get the SelectionDAG to > do it for me via something like visitGetElementrPtr? SelectionDAGBuilder::visitGetElementPtr uses the same algorithm you want to use, but it is specialized for building a SelectionDAG, which is lower level than LLVM IR. -Eli >

I'm trying to change the Endian of X86 from little to big in the TargetData. I only care about the way in which this effects the LLVM IR, not the actual backend code. I've changed the "e-" to "E-" in X86TargetMachine.cpp (where it sets the DataLayout) with no luck. Are there any other obvious places that I need to change this? The TargetData docs were somewhat helpful

After some thought, to put this more simply (more direct), it would be fine if the getelementptr is lowered into IR assuming an x86 architecture. The real problem is that I don't want the x86 code generation, I still want to deal in LLVM IR just with the GEP lowered, and it lowered for the x86 architecture is fine. Is there any way to do this? On Thu, Dec 8, 2011 at 11:39 AM, Ryan Taylor

For the gep: %idx1 = getelementptr i32* %MyVar, i32 0 i32* is the type that MyVar is pointing to and i32 is the type of the offset value, or what? If it's the type of offset value, then the size of the pointer shouldn't be less than i32, correct? The index is 0, so in this example, the address computation is idx1 = &MyVar+0. What I want to know is the size in bits of the values

On Thu, Dec 8, 2011 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Thanks. > > So basically then this operation is not target-independent like the docs > suggest? > > > On Thu, Dec 8, 2011 at 1:23 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > >> On Thu, Dec 8, 2011 at 11:49 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >>

On Wed, Aug 15, 2012 at 3:17 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > So there are some #define (defined outside the function scope) that use > it_tab that are used inside the function, is this why it is promoting it to > a global? Macros shouldn't matter. Please give a complete testcase and steps to reproduce. And please don't top-post. -Eli > > On Wed,

#define r10(p,q,r,s) 0x##s##r##q##p #undef r #define r r10 const word it_tab[4][256] = { r(const, const, const, const), r(.......), r(.......) ....... }; All of this is done inside the function I want the alloc in. The variable is not declared/defined/used anywhere else. On Wed, Aug 15, 2012 at 12:00 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Wed, Aug 15, 2012

Seems like bad behavior to just decide to delete the function, no? Why not just ignore it then and output the input? On Fri, Feb 10, 2012 at 2:43 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Feb 10, 2012 at 2:38 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I have some code that has one function and if I use the-inline on it then > > these opts

Unfortunately, I cannot provide the exact code, but I will attempt to look for the reason and post a test case. On Tue, Feb 7, 2012 at 6:04 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Feb 7, 2012 at 5:52 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > opt: > /home/ryan/llvm/llvm_core/llvm-3.0/include/llvm/Support/Casting.h:194: > > typename

On Thu, Dec 8, 2011 at 6:07 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Eli, > >    Ok, thanks, this is a big help. So how can I use the TargetData (or get > the TargetData) without having a DAG? If you're writing a transformation pass, just write "getAnalysisIfAvailable<TargetData>()" to get a TargetData*. -Eli

Yes, that makes sense but not if it isn't doing anything with it. If it doesn't inline it then it shouldn't be modifying it, or at least that's what makes sense to me. If part of it's job is to delete functions that were created "dead" by some other opt, then shouldn't that opt be deleting the functions it makes dead? I guess I don't see the point in deleting