[LLVMdev] [PATCH] Handle tied sub-operands in AsmMatcherEmitter

[Jim Grosbach]

On Apr 25, 2013, at 10:03 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:

> Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 25.04.2013 18:58:05:
> 
>> On Apr 25, 2013, at 4:44 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com>
> wrote:
>> 
>>> Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54:
>>> 
>>>> I would like to add one more case here: Fixed register operands.
>>>> 
>>>> Some instructions, like x86's MUL and DIV, take operands in fixed
>>>> registers. Currently, we handle that with COPY instructions to and
>>>> from the fixed registers, but that is making code motion passes more
>>>> complicated than they need to be. (Actually, they usually just run
>>>> away when they see one of these instructions).
>>>> 
>>>> I would like to have MUL32r take two virtual register operands, one
>>>> of them tied to the fixed register %EAX. Just like two-address
>>>> instructions, it would be the register allocator's responsibility to
>>>> satisfy the constraint. This would also make it possible to write
>>>> proper isel patterns for MUL and DIV.
>>> 
>>> I'm wondering: is is not possible to handle this case by using a
>>> register class containing just the one register?
>> 
>> I think that would work too. Either way, you get MI operands that
>> aren't encoded.
> 
> Right.  Well, in any case this would also seem to argue for the rule
> I suggested in my other email: the MC operand list should consist of
> exactly those operands that are named in the AsmString.
> 

Perhaps we could/should have tablegen collect singleton registers like this and auto-generate the singleton register classes, instruction operands, etc? There might need to be some syntax in the (ins) and (outs) lists, too? Unclear. In general, I like being able to write instructions like this in the naive way and have tblgen figure out the rest.

-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130426/c2ff58d2/attachment.html>