[LLVMdev] getelementptr and SCEVs

Chris Lattner sabre at nondot.org
Fri Mar 2 14:41:34 PST 2007


On Thu, 1 Mar 2007, Dan Gohman wrote:
>> It really depends on what you're trying to do.  Can you say what
>> optimization of code xform you're trying to accomplish?
>
> Well, primarily I'm just trying to learn a few things :-).

Ah, very good.

> At the moment I'm working on a pass to do simple prefetching, using SCEVs
> to look at how the addresses of load instructions evolve in loops. Beyond
> that, I'm interested in looking at loop memory footprints in general.

Okay, there are two different ways to do this.  If you want to do this in 
the context of the loop optimizer, retaining the getelementptr 
instructions is important.  If you're doing this in preparation to run the 
code generator (like the loop strength reduction pass) this doesn't 
matter.  In the later case, treating pointers like integers, and lowering 
addressing to explicit arithmetic makes sense.

>> As I mentioned before, SCEV is really designed for integer expressions,
>> not pointer expressions.  Fortunately, all pointers can be treated as
>> integers, and GEP is really just doing some integer arithmetic.  Given
>> something like this:
>>
>> P = getelementptr i32* %A, i32 %Idx
>>
>> The result pointer is actually equivalent to (on a 32-bit machine):
>>
>>    (i32*)((i32)%A + Idx*4)
>
> I guess that'll work, though it makes working with multidimensional arrays
> trickier. However, this kind of thing may be unavoidable in the case of
> multidimensional arrays with variable extents anyway, since LLVM's type
> system doesn't represent that directly.

Right.

> On a related note, I'm surprised there's no sign-extend SCEV. Is that
> intentional or is it just not done yet?

There wasn't a need for it, so it wasn't done yet :)

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/



More information about the llvm-dev mailing list