[llvm-dev] Register allocation constraints

黄岚之观 via llvm-dev llvm-dev at lists.llvm.org
Sat Oct 12 19:20:22 PDT 2019


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>


More information about the llvm-dev mailing list