[llvm-dev] Mapping virtual registers to physical registers

[Dominique Torette via llvm-dev]

Hi,

In the context of MachineCode custom inserter, I'm trying to enforce the mapping of virtual register to a physical one.

According to the documentation https://llvm.org/docs/CodeGenerator.html#mapping-virtual-registers-to-physical-registers
There are two ways: the direct one and the indirect ones. The indirect ones refer VirtRegMap class that I've never found. So I tried the direct one...

Mapping virtual registers to physical registers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

There are two ways to map virtual registers to physical registers (or to memory
slots). The first way, that we will call *direct mapping*, is based on the use
of methods of the classes ``TargetRegisterInfo``, and ``MachineOperand``. The
second way, that we will call *indirect mapping*, relies on the ``VirtRegMap``
class in order to insert loads and stores sending and getting values to and from
memory.

The direct mapping provides more flexibility to the developer of the register
allocator; however, it is more error prone, and demands more implementation
work.  Basically, the programmer will have to specify where load and store
instructions should be inserted in the target function being compiled in order
to get and store values in memory. To assign a physical register to a virtual
register present in a given operand, use ``MachineOperand::setReg(p_reg)``. To
insert a store instruction, use ``TargetInstrInfo::storeRegToStackSlot(...)``,
and to insert a load instruction, use ``TargetInstrInfo::loadRegFromStackSlot``.

...

I tried the direct mapping as following:

            MachineOperand destination = MI->getOperand(0);
            MachineOperand offset = MI->getOperand(1);

            unsigned destinationReg = destination.getReg();
            int64_t  FrameIndex = offset.getIndex();

                destination.setReg(CLP::FA_ROFF0+FrameIndex);
                destination.setIsDef(true);

                TII->loadRegFromStackSlot(*MBB,
                                                MI, destinationReg, FrameIndex,
                                                &CLP::FPUaOffsetClassRegClass, TRI);

The code after customInserter seems valid but the compilation later hang-up in an infinite loop in procedure computeVirtRegs(); of pass LiveIntervals::runOnMachineFunction.
In other targets, I've seen an example with a setIsDef(true) for such physically mapped register. Is there something missing in my code (register other setting,...) ?





[http://www.spacebel.be/wp-content/uploads/2011/06/image-sign-sbp.jpg]

Dominique Torette
System Architect
Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20
www.spacebel.be<http://www.spacebel.be/>



 ------------------------------------------------------------------------------

E-MAIL DISCLAIMER

The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.

SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.

SPACEBEL denies all liability where E-mail is used for private use.

SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
 -------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180329/626bd14e/attachment.html>