[llvm-dev] TableGen operand question

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Sun Jun 12 06:01:34 PDT 2016


On 10 June 2016 at 14:13, Simon Cook via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi Dawid,
>
> I've had to do something similar for a different backend, whereby I use
> memory locations as a substitute for registers in something rather
> register-contrained, and I hope this may be relevant to the issue you're
> trying to solve.
>
> How I would tackle this is to create a register class full of pseudo
> registers where each one represents one memory location, and do
> instruction selection and register allocation on that. Once that is
> complete, I would have a pass which goes through each instruction in a
> MachineFunction and replace the operands with the reference to memory
> and emit that. In my case these pseudo registers lived on a stack, so
> the replacement wasn't too difficult, I don't think replacing registers
> with symbols would be any harder than that. Once complete it's just a
> matter of having your assembler and linker handle these references
> (though you should be able to generate some assembly directives to help
> here also). Note may have to store some data in your targets
> MachineFunctionInfo class to help keep track of the real size of a
> frame, as asking a MachineFunction will now give the wrong result.
>
> One consideration would be the size of this register class (that is, the
> number of pseudo registers you create). If you make it too large and you
> may end up wasting memory, though I'm not sure exactly what the register
> allocations will do in this case if given far too many registers for a
> given problem. If you make it too small, you'll have to start thinking
> about how to spill memory locations to other memory locations (or
> rewriting generated code post-regalloc to avoid this).

In your scheme, do you reduce the required stack storage to match the
number of pseudo-registers actually used?

The register allocator currently tries to use the minimum number of
registers, which in this case is exactly what you want. There was some
recent discussion on adding the ability to try to use the maximum
number of architectural registers in order to reduce false
dependencies http://lists.llvm.org/pipermail/llvm-dev/2016-May/099494.html

Alex


More information about the llvm-dev mailing list