[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

[Bob Wilson]

On Jul 12, 2009, at 11:56 AM, Chris Lattner wrote:

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

I could definitely go that route, i.e., define one MVT for the new  
Neon regclasses instead of adding all these new vector types.  I don't  
think it would make much difference either way in terms of getting  
Neon to work.

(I had mentioned in an email yesterday that an alternative to the new  
types would be defining a separate intrinsic for each type.  I  
realized later that would be silly.  We could just use arguments to  
the intrinsics to specify the element size and vector length.)

It sounds like you would prefer to avoid adding all the new vector  
types.  Is that right?