similar to: [LLVMdev] Break GEP into arithmetic

No I think I misunderstood you, I actually want the GEP broken down into it's arithmetic instructions, I don't want any GEP instructions in my code at all. Is there a way to do that? On Wed, Dec 7, 2011 at 2:24 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > On Wed, Dec 7, 2011 at 1:50 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> There is a

On Wed, Dec 7, 2011 at 1:50 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > There is a GEPSplitterPass in the Scalar.h but not in the > LLVM_SRC/lib/Transforms/Scalar folder, there is no GEPSplitterPass.cpp > file. Is it possible to get this from 2.8 and compile it and use it for 2.9? > > > On Wed, Dec 7, 2011 at 12:31 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:

Or is it in the docs such that when you use the word "independent", you really mean "independent of a particular target" and not actually "target independent"? On Thu, Dec 8, 2011 at 11:18 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Ryan Taylor <ryta1203 at gmail.com> > Date: Thu,

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Thu, Dec 8, 2011 at 11:13 AM Subject: Re: [LLVMdev] GetElementPtr To: Reid Kleckner <reid.kleckner at gmail.com> There is no support for gep, it's my understanding that it's target-independent, so there's no reason to put the lowering in the target lowering portion is there?

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

Does a transform exist to breakdown the GEP? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111206/e88dddfe/attachment.html>

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

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

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:

Do you think I could use the SelectionDAGBuilder in a pass to accomplish this for me? if there is already code that does this I don't really think I should have to do this again, unless it's not possible to access that code from the stage where I want to use it? On Thu, Dec 8, 2011 at 12:56 AM, Pedro Ferreira <pedro.ferreira at imgtec.com>wrote: > I was unaware of its removal.

> Note that InstCombine is not the only place that tries to insert pointer-width GEPs in the optimization pipeline. I think that we’ve fixed all of them, but I can’t be entirely sure. I'm going to upload a patch, but I'm fixing only the places that are covered by our test system. I'll add you as a reviewer and you are welcome to help me with fixing them all. > We haven’t

> On 15 Jan 2018, at 18:21, Demikhovsky, Elena via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I’m working on an out-of-tree target and encountered the following problem: > > InstCombiner “normalizes” GEPs and extends Index operand to the Pointer width. > It works fine if you can convert pointer to integer for address calculation and I assume

On 01/15/2018 12:59 PM, Demikhovsky, Elena wrote: > > I tried to retrieve anything from DataLayout. It contains pointer > size, but how can I conclude that the GEP index can’t be widened? > I meant that we'd add a new field giving the preferred size for indexing arithmetic.  On the other hand, in your case, and in general, would it make sense to prevent widening beyond the largest

On 01/15/2018 12:21 PM, Demikhovsky, Elena wrote: > Hi all, >   > I’m working on an out-of-tree target and encountered the following > problem: >   > InstCombiner “normalizes” GEPs and extends Index operand to the > Pointer width. > It works fine if you can convert pointer to integer for address > calculation and I assume that all registered targets do this. >   >

I tried to retrieve anything from DataLayout. It contains pointer size, but how can I conclude that the GEP index can't be widened? - Elena From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, January 15, 2018 20:34 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; llvm-dev at lists.llvm.org; Sanjay Patel (spatel at rotateright.com) <spatel at

On 9-Mar-09, at 12:14 AM, Chris Lattner wrote: > GEP overflow is undefined, but this sentence means that *accesses* to > an array must be within its bounds. It is fine to GEP outside the > array as long as you readjust the pointer back before access. Thanks, that was my hope. Maybe this should be spelled out in the langref, especially since it's inconsistent with C, where merely

Hi, all I am trying to use GEP to get a pointer of i32 from an array. But the problem is: I don't know the size of the array. The IR document on llvm.org said GEP just adds the offsets to the base address with silently-wrapping two’s complement arithmetic. So, I want to ask for some advice. Is it safe like this: %v1 = alloca i32 store i32 5, i32* %v1 %6 = load i32* %v1 %7 = bitcast i32* %v0

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

----- Original Message ----- > > On Oct 31, 2013, at 1:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > Andy, et al., > > > > If I start with C code like this: > > > > void foo(long k, int * restrict a, int * restrict b, int * restrict > > c) { > > if (k > 0) { > > for (int i = 0; i < 2047; i++) { > > a[i] =