[LLVMdev] Register based vector insert/extract

[Chris Lattner]

On Tue, 24 Apr 2007, Christopher Lamb wrote:
>>> I have other higher priority tasks right now, but I think we'll want
>>> to have this in sooner rather than later. If you have any pointers on
>>> a good starting point it'd be mighty helpful. If I can get a grasp on
>>> it I'll start incremental work in the background.
>>
>> It's really unclear how we will implement this. I haven't given it
>> much thought because it's not yet important for us. If you have
>> ideas, please share. :-)

hehe, I've been thinking about this for years :)

> Chris had some suggestions about 2 posts back <http://
> lists.cs.uiuc.edu/pipermail/llvmdev/2007-April/008834.html>
>
> He mentioned that the place where the constraint would need to be
> enforced was during the register rewriting pass.
>
> My first productive thoughts were to create a subclass of SDOperand
> (SDSubOperand) that Lowering could use to communicate the target
> specific subregister index. The other thought was to have something
> akin to "getSubRegisterForIndex()" in MRegisterInfo, which would
> return a sub register of the correct type at the specified index in a
> target dependent way. I'm not familiar with the register rewriting
> pass, so I'm not sure what data structures it needs/has access to.

Yes, we need those.  I think these are the major pieces needed.  These are 
all relatively small and independent pieces, so we can tackle these one at 
a time.

1. As you say, we need MRegisterInfo::getSubRegisterForIndex that, given a
    preg/subreg# pair, returns a preg.
2. We need tblgen syntax/registerinfoemitter support to generate tables
    for #1.
3. Register MachineOperands need a subregister number.  We should probably
    use 0 to denote "no subreg".
4. The DAG scheduler pass (which creates machine instrs from dag nodes)
    currently thinks of register operands as simple unsigned's for vreg
    #'s.  This needs to be extended to be vreg+subreg pairs (see
    'CreateVirtualRegisters').
5. We need to decide how to represent subregs in the DAG.  Your
    SDSubOperand idea is fine, but I don't think it needs to be an actual
    new subclass of SDOperand.  Instead, it could just be a binary SDNode,
    where the LHS is the register input and the RHS is a TargetConstant
    specifying the subreg#.
6. [optional] We would like syntax to create these things for writting
    patterns in the .td file instead of requiring custom matching code. 
7. The register allocator needs to rewrite subreg references using
    #1.  This should be very simple.

-Chris

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