[llvm-commits] [llvm] r75308 - in /llvm/trunk: include/llvm/CodeGen/ValueTypes.h include/llvm/CodeGen/ValueTypes.td lib/VMCore/ValueTypes.cpp utils/TableGen/CodeGenTarget.cpp

[Chris Lattner]

On Jul 12, 2009, at 6:16 AM, Anton Korobeynikov wrote:
> Hi, Chris
> I don't know about much about neon, but if you are using this to model
>> load/store with multiple registers, there are probably better ways to
>> go.  What set of operations does neon natively support on these
>> datatypes?
> I also faced with similar problem and it seems it's a deficiency of
> current regalloc. There is common situation that some instructions
> operate on regpairs. Currently there is no way to say stuff like
> "allocate this argument from odd-numbered register" or "keep this two
> operands in two consecutive registers".
>
> If the instruction accepts only certain regpair (e.g. x86's div /
> idiv)

X86 idiv isn't a big problem, because it is two specific registers,  
the allocator doesn't need to do anything fancy here.

> when we can go into hacky way and expand stuff by hands (another
> example is ARM argument lowering). Otherwise I don't see any other way
> except defining virtual regclass holding register pairs with all
> needed reg alias sets, etc.

Right, this is a reasonable way to go.  However, you only need to  
define one MVT for the regclass to use, and you can internally do  
bitcast + insert/extractsubreg to get to other types.  For example,  
you could define a regclass as <8 x float> and still use it for <8 x  
int> etc.

> This regclass should be special though
> since the type it's holding is not 'native' type legalizer should
> expand all operations with such type (We already have special case
> during type legalization of ppcf128 - it behaves exactly this way).

Right, just don't declare the regpair regclass as "legal" at isel  
lowering time.

-Chris