[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,…) ?
|
|
|
Dominique Torette
|
------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
Dominique Torette via llvm-dev
Hi again,
After further investigation, I’ve found that the private PhysRegUseDefLists array (“head of use/def list for physical register”) from MachineRegisterInfo class seems to be empty.
But I didn’t found any methods for updating such data structure. How/where this “use/def list” should be managed ?
Is the documentation https://llvm.org/docs/CodeGenerator.html#mapping-virtual-registers-to-physical-registers still valid ?
Are there other options to enforce the mapping of virtual registers to physical ones ?
TIA, Dominique Torette.
陳韋任 via llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Homepage: https://people.cs.nctu.edu.tw/~chenwj
Krzysztof Parzyszek via llvm-dev
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
> *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...@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
Dominique Torette via llvm-dev
I was trying to map function input parameters to machine specific registers.
My solution I found is based to the RegInfo.setSimpleHint() API.
Here is the body of the parameters loop of TargetLowering::LowerFormalArguments
VReg = RegInfo.createVirtualRegister(RC);
RegInfo.setSimpleHint(VReg,CLP::FA_ROFF1+i);
RegInfo.addLiveIn(CLP::FA_ROFF1+i, VReg);
Load = DAG.getCopyFromReg(Chain, Loc, VReg, ValVT.getSimpleVT().SimpleTy);
Thanks again for your support, Dominique T.
-----Original Message-----
From: llvm-dev [mailto:llvm-dev...@lists.llvm.org] On Behalf Of Krzysztof Parzyszek via llvm-dev
Sent: lundi 2 avril 2018 17:00
To: llvm...@lists.llvm.org
Subject: Re: [llvm-dev] Mapping virtual registers to physical registers
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://clicktime.symantec.com/a/1/qLQUsovqBxYmtEpyYF4Fx_S26wH68VrDlLt
> fEAs6I_0=?d=zjKiRR7eOkU7w-B6rd8m5DDFsuNq0PcW_s7qRxc5ku1F7yXxMJEw8ft1Ex
> iCifu0BPMerFoBFrT1JAqrzo7iQxrqs4u5jTVZ2BrGfjOkKHlik8H1JTR3dPKAjd1x7qZu
> 3sZ791xRJbzh2b5nJ0nESfPbU_raIgWS_KlIwv7CzR5jgqBC8_UjcS8INrg9DYAa91YEoB
> nkpMsR5nmwxOwHxrg94ARv15Jkau47BqHfowR2wmELfIzFjh_umT7Vkr9jI9c6qcXoXvYb
> 5Kcvn9UXp5j4tOO58iozjnB9tHzCgUaZ6WKB8DV7xv6mS_2viUKUH6uVrHPT7rOBc6qTqL
> KQGnXVlZbRYkPIMz4nXqAE_hx5OTnCQuchlvSGaegNVz_YFL-j9TwL6mwpTBgzOcmlem_T
> fEo1SyMKgZDQ6UntyqHr_2Z1UA%3D%3D&u=https%3A%2F%2Fllvm.org%2Fdocs%2FCod
> eGenerator.html%23mapping-virtual-registers-to-physical-registers
> https://clicktime.symantec.com/a/1/SkcUKSTguelZdoQ0cCShN0FUpnRosHtFjFV
> 8WvXHfPg=?d=zjKiRR7eOkU7w-B6rd8m5DDFsuNq0PcW_s7qRxc5ku1F7yXxMJEw8ft1Ex
> iCifu0BPMerFoBFrT1JAqrzo7iQxrqs4u5jTVZ2BrGfjOkKHlik8H1JTR3dPKAjd1x7qZu
> 3sZ791xRJbzh2b5nJ0nESfPbU_raIgWS_KlIwv7CzR5jgqBC8_UjcS8INrg9DYAa91YEoB
> nkpMsR5nmwxOwHxrg94ARv15Jkau47BqHfowR2wmELfIzFjh_umT7Vkr9jI9c6qcXoXvYb
> 5Kcvn9UXp5j4tOO58iozjnB9tHzCgUaZ6WKB8DV7xv6mS_2viUKUH6uVrHPT7rOBc6qTqL
> KQGnXVlZbRYkPIMz4nXqAE_hx5OTnCQuchlvSGaegNVz_YFL-j9TwL6mwpTBgzOcmlem_T
> fEo1SyMKgZDQ6UntyqHr_2Z1UA%3D%3D&u=http%3A%2F%2Flists.llvm.org%2Fcgi-b
> in%2Fmailman%2Flistinfo%2Fllvm-dev
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
Krzysztof Parzyszek via llvm-dev
Using setSimpleHint shouldn't be necessary for correctness. Does
anything fail without it? For correctness, the "RegInfo.addLiveIn" and
the copies from physical regs into the vregs matching the addLiveIn
arguments should be enough.
Typically, though, you wouldn't specify physical registers directly in
LowerFormalArguments. Instead, the CallingConv mechanism is used that
automatically assigns physical registers to incoming parameters
according to the calling convention definition that you'd provide in a
.td file. It's not absolutely required, just the usual way of doing this.
-Krzysztof