[LLVMdev] [PATCH] Handle tied sub-operands in AsmMatcherEmitter
Jim Grosbach
grosbach at apple.com
Fri Apr 26 16:06:40 PDT 2013
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>
More information about the llvm-dev
mailing list