llvm dev - Oct 2019 - Register allocation constraints

Hi,
  I have a problem during my development of a backend. There are some
target instructions with multiple outputs, for example an instructionX with
2 inputs and 2 outputs:
  def1, def2 = InstructionX op1, op2
  The defs above must be allocated in consecutive target physical registers.
  Is it possible to describe the constraints with tablegen and let the
register allocator get all the things done or is regalloc hints related api
designed just to solve the problem? Any suggestions?
  Thanks

lanzhiguanhuang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191012/1e3a5c1f/attachment.html>

Hi,


On Sat, 12 Oct 2019 at 10:47, 黄岚之观 via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>   I have a problem during my development of a backend. There are some
target instructions with multiple outputs, for example an instructionX with 2
inputs and 2 outputs:
>   def1, def2 = InstructionX op1, op2
>   The defs above must be allocated in consecutive target physical
registers.
>   Is it possible to describe the constraints with tablegen and let the
register allocator get all the things done or is regalloc hints related api
designed just to solve the problem? Any suggestions?
This is common enough that I think it's handled reasonably
automatically in LLVM. You need to create a new register-class based
on a RegisterTuple in TableGen. The example I'm most familiar with
that's reasonably clean is AArch64's XSeqPairs (and others). They have
the extra constraint that the first register has to be even-numbered
so watch out for that if copy/pasting but otherwise are pretty
straightforward.

LLVM then handles the register allocation and so on if any instruction
uses them as operands, but you might need custom C++ to for the MC
stuff (encoding, decoding , asmprinting, asmparsing).

Also, CodeGen is often tricky: these operations often only exist for
types that would be illegal in almost all other cases (i128 on a
64-bit machine) so C++ code is probably needed to make CodeGen use
them. If not, then in principle things should be simpler (you can give
your tuple RegisterClass some types), but I've never seen it in
practice.

Cheers.

Tim.

Thanks a lot!

On Sun, Oct 13, 2019 at 2:06 AM Tim Northover <t.p.northover at gmail.com>
wrote:
> Hi,
>
>
> On Sat, 12 Oct 2019 at 10:47, 黄岚之观 via llvm-dev <llvm-dev at
lists.llvm.org>
> wrote:
> >   I have a problem during my development of a backend. There are some
> target instructions with multiple outputs, for example an instructionX with
> 2 inputs and 2 outputs:
> >   def1, def2 = InstructionX op1, op2
> >   The defs above must be allocated in consecutive target physical
> registers.
> >   Is it possible to describe the constraints with tablegen and let the
> register allocator get all the things done or is regalloc hints related api
> designed just to solve the problem? Any suggestions?
>
> This is common enough that I think it's handled reasonably
> automatically in LLVM. You need to create a new register-class based
> on a RegisterTuple in TableGen. The example I'm most familiar with
> that's reasonably clean is AArch64's XSeqPairs (and others). They
have
> the extra constraint that the first register has to be even-numbered
> so watch out for that if copy/pasting but otherwise are pretty
> straightforward.
>
> LLVM then handles the register allocation and so on if any instruction
> uses them as operands, but you might need custom C++ to for the MC
> stuff (encoding, decoding , asmprinting, asmparsing).
>
> Also, CodeGen is often tricky: these operations often only exist for
> types that would be illegal in almost all other cases (i128 on a
> 64-bit machine) so C++ code is probably needed to make CodeGen use
> them. If not, then in principle things should be simpler (you can give
> your tuple RegisterClass some types), but I've never seen it in
> practice.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191013/28b96575/attachment.html>