[llvm-dev] Mapping virtual registers to physical registers

Krzysztof Parzyszek via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 2 07:59:53 PDT 2018


Hi Dominique,

 From your description it is not really clear what you are trying to do 
here. It may be the case that the goal you are trying to accomplish can 
be better reached using a different approach.
In general, optimizations don't try to assign physical registers, that's 
done by the register allocation passes. There are some cases when 
target-specific passes use physical registers before register 
allocation, but these registers are usually reserved (such as frame 
pointer, status register, etc.)

You can use non-reserved registers before register allocation, it's just 
that it's not something typical. If your backend tracks register 
liveness, you will need to make sure that the physical registers that 
you use are properly marked as live-in in appropriate basic blocks. 
Also, you can only use physical registers in COPY instructions, either 
as the source, or as the destination. You should not use non-reserved 
physical registers directly in instructions. For example, you'd have 
something like this:
   %virt_reg0 = COPY $phys_reg
   %virt_reg1 = some_instr %virt_reg0, ...
   $phys_reg = COPY %virt_reg1

The functions "load/store from stack slot" are used for spills/restores. 
They do exactly what their names suggest and they are not required to be 
used (unless, of course, you want to generate a load/store).

In the code snippet below you create a local copy of MachineOperand, and 
then modify it. I'm assuming it's a typo because the changed made by 
calling setReg will be discarded one you go out of scope. Having said 
that, setReg can be used to change the register in the given operand. 
Make sure to change the subregister to 0, since physical registers are 
not allowed to have explicit subregisters in machine operands. Calling 
setIsDef on an existing operand is not a good practice. If you want to 
make significant changes to an instruction, it's usually better to build 
a new one and remove the old one.

Hope this helps,
-Krzysztof

On 3/29/2018 8:47 AM, Dominique Torette via llvm-dev wrote:
> 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/2018/02/image-sign-sbp30y-1.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.
> -------------------------------------------------------------------------------
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation


More information about the llvm-dev mailing list