[LLVMdev] Load/Store issues: tablegen/customization?

[Dan Gohman]

On Nov 10, 2008, at 1:20 PM, Daniel M Gessel wrote:

> I've been running into two issues with load/store handling:
>
> (1) is that tablegen doesn't seem to handle the two predicates that
> get attached to my instructions. The first is the predicate in
> TargetSelectionDAG.td, identifying a load node as, say, extloadi8. The
> second is my identification of the load as having a particular address
> space (need different instructions for different address spaces).
>
> In the tablegen generated code, only one predicate is tested. Anybody
> seen anything similar to this (i.e. is this a known issue)? Do people
> have experience with multiple predicates working just fine?
>
> I've been directly matching "ld" and been testing in a world that only
> does 32 bit aligned loads and things have "just worked", but I've got
> my sights set higher now (load of bytes, store of 4 x byte vectors,
> etc).

What version of LLVM are you using? I recently made some tablegen
changes to allow nodes to have multiple predicates. See r57565 for
an example of a change made possible by being able to have multiple
predicates on a node, and it sounds similar to what you describe.

>
>
> (2) The HW I'm targeting does not have byte/short load/store; the
> finest granularity is aligned 32 bit load/store (like the original
> Alpha architecture). In addition, I want to optimize certain vector
> operations (128 bit load/store) and some are getting converted from 32
> bit to multiple 8 bit operations (e.g. store a 4 element vector of
> chars becomes 4 one byte stores), but I don't want to provide full
> vector register support (at this time).
>
> Any hints on a good approach to dealing with the 32 bit aligned load/
> store limitations and mixing and matching "native" load/store support
> of vector types with LLVM generated expansions of vector operations?

For the 32-bit load/store question, I think you should mark
loads and stores of i8 and i16 as Custom, which will allow
you to write target-specific code to handle them. For the
vector question, it sounds like a target-specific DAGCombine
may be a possible solution.

Dan