[LLVMdev] Custom load/store code: determining offset or alignment

[Chris Lattner]

On Fri, 5 Jan 2007, Scott Michel wrote:
> Firstoff, let me say what a mind fsck the Cell SPU can be. It's really
> not that hard an architecture to get one's mind around, but I can see
> how it becomes a compiler writer's nightmare.

:)

> And I'm attempting to write a SPU backend. And it's going slowly.

ok

> Here's my problem: The SPU's registers are all 128-bit vector registers.
> That's their native mode. They can be used as 8-, 16-, and 32-bit
> registers for PODs, with certain result propagation consequences. For
> example, you can load a constant into a register's "preferred slot"
> (where POD data goes), but the constant propagates to all other vector
> elements (making scalar_to_vector transforms significantly easier, but
> that's beside the point here.) Moreover, to get what is termed
> "unaligned" POD data from its vector element into the preferred slot
> requires doing vector perm-ing and shuffling.

Ok.

> Consequently, this unique register set makes writing the instruction
> description significantly more challenging. Loads and stores for PODs
> and non-vector types (seemingly) have to be custom lowered in
> TargetLowering::LowerOperation and custom selected in
> SelectionDAGISel::Select.
>
> Q1: Is there any way I can determine a POD's offset and check its
>    alignment as a predicate in the tblgen files? If so, this would
>    likely take care of the normal case if the POD is on the stack
>    and writing patterns is a lot easier than custom selecting or
>    lowering.

Yes.  The Load/StoreSDNode both keep an alignment of the access.  You 
should base your code off this.  I don't think that this field is 
currently used by much, so you may find bugs in its computation.  Further, 
we should add some analysis to the dag combine pass which uses analysis to 
increase the alignment field of the load/store when it can prove that it 
is safe.

> Q2: Is there any way to determine a POD's offset based on a LoadSDNode
>    and StoreSDNode's data? Currently, LoadSDNode::getBasePtr (and
>    StoreSDNode::getBasePtr) can return something back, but how do I
>    access the operand's offset (and hence, alignment) relative to a
>    base register?

Offset from what?

> Q3: There are three variants of load (and store) for the SPU. Two of the
>    variants take 10- and 16-bit sign extended offsets, whereas the
>    third is reg+reg. If I have to custom lower and select, knowing the
>    offset would make it easier to determine which variant to use, if
>    tblgen pattern matching isn't an option. Can I do this?

Typical backends defer address mode selection until the 'select' pass. 
You want to know the offset at lowering time?

-Chris

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