Dominique Torette via llvm-dev
2018-Mar-29 13:47 UTC
[llvm-dev] Mapping virtual registers to physical registers
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>
Dominique Torette via llvm-dev
2018-Mar-30 12:27 UTC
[llvm-dev] Mapping virtual registers to physical registers
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<https://clicktime.symantec.com/a/1/VD92eMlNQNYWvTHMFGJ6d9CoI8TWzptcPQ9N_WgcsEc=?d=BGAdaOmUwTeTJGDCY0PxccF0_w2aXYWPkZ7TqUaX5BfIwvuies1FpFGWK0a0V-ztU78uUhUTIHuntFNIacX_7R-N7h4qVswHza4R-xOhmPRaQu6xRDCjEZfI6H1_u4borbcUPyDQ6liK-yuculXq6ICDidJQPJtYEveno35W1lltgoNkAeIagO29GvgnsgoziKJ4U4zRUDXIZwQeuBXTC3NRd9iLtHz1IZhXsFCNmIC7QGkD278pz90U42sWT96yrGQLpPfsfpg05TFLkE_BGipWpMwKeLCYUqii7-0V9sOqCdVrNOfjC3Ruk9eeyMyFZS5pjXRNSNFElfHytB77QRZC87cWwM8aULV5KlIMMkmasWMWav7pb5xQc8VgqrXKzD2DtrP8F80Uyc48XqNNjuzvmT7TK7cDvvzhGtUvS4WXZfr-70e3-6fpQa4k&u=https%3A%2F%2Fllvm.org%2Fdocs%2FCodeGenerator.html%23mapping-virtual-registers-to-physical-registers>
still valid ?
Are there other options to enforce the mapping of virtual registers to physical
ones ?
TIA, Dominique Torette.
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Dominique Torette via llvm-dev
Sent: jeudi 29 mars 2018 15:48
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] Mapping virtual registers to physical registers
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<https://clicktime.symantec.com/a/1/VD92eMlNQNYWvTHMFGJ6d9CoI8TWzptcPQ9N_WgcsEc=?d=BGAdaOmUwTeTJGDCY0PxccF0_w2aXYWPkZ7TqUaX5BfIwvuies1FpFGWK0a0V-ztU78uUhUTIHuntFNIacX_7R-N7h4qVswHza4R-xOhmPRaQu6xRDCjEZfI6H1_u4borbcUPyDQ6liK-yuculXq6ICDidJQPJtYEveno35W1lltgoNkAeIagO29GvgnsgoziKJ4U4zRUDXIZwQeuBXTC3NRd9iLtHz1IZhXsFCNmIC7QGkD278pz90U42sWT96yrGQLpPfsfpg05TFLkE_BGipWpMwKeLCYUqii7-0V9sOqCdVrNOfjC3Ruk9eeyMyFZS5pjXRNSNFElfHytB77QRZC87cWwM8aULV5KlIMMkmasWMWav7pb5xQc8VgqrXKzD2DtrP8F80Uyc48XqNNjuzvmT7TK7cDvvzhGtUvS4WXZfr-70e3-6fpQa4k&u=https%3A%2F%2Fllvm.org%2Fdocs%2FCodeGenerator.html%23mapping-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.
-------------------------------------------------------------------------------
------------------------------------------------------------------------------
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/20180330/6689eb43/attachment-0001.html>
陳韋任 via llvm-dev
2018-Mar-30 14:39 UTC
[llvm-dev] Mapping virtual registers to physical registers
For direct mapping, I guess you can `grep addReg` in `lib/Target` to see how things done. HTH, chenwj 2018-03-30 20:27 GMT+08:00 Dominique Torette via llvm-dev < llvm-dev at lists.llvm.org>:> 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 > <https://clicktime.symantec.com/a/1/VD92eMlNQNYWvTHMFGJ6d9CoI8TWzptcPQ9N_WgcsEc=?d=BGAdaOmUwTeTJGDCY0PxccF0_w2aXYWPkZ7TqUaX5BfIwvuies1FpFGWK0a0V-ztU78uUhUTIHuntFNIacX_7R-N7h4qVswHza4R-xOhmPRaQu6xRDCjEZfI6H1_u4borbcUPyDQ6liK-yuculXq6ICDidJQPJtYEveno35W1lltgoNkAeIagO29GvgnsgoziKJ4U4zRUDXIZwQeuBXTC3NRd9iLtHz1IZhXsFCNmIC7QGkD278pz90U42sWT96yrGQLpPfsfpg05TFLkE_BGipWpMwKeLCYUqii7-0V9sOqCdVrNOfjC3Ruk9eeyMyFZS5pjXRNSNFElfHytB77QRZC87cWwM8aULV5KlIMMkmasWMWav7pb5xQc8VgqrXKzD2DtrP8F80Uyc48XqNNjuzvmT7TK7cDvvzhGtUvS4WXZfr-70e3-6fpQa4k&u=https%3A%2F%2Fllvm.org%2Fdocs%2FCodeGenerator.html%23mapping-virtual-registers-to-physical-registers> still > valid ? > > Are there other options to enforce the mapping of virtual registers to > physical ones ? > > > > TIA, Dominique Torette. > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Dominique > Torette via llvm-dev > *Sent:* jeudi 29 mars 2018 15:48 > *To:* llvm-dev at lists.llvm.org > *Subject:* [llvm-dev] Mapping virtual registers to physical registers > > > > 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 > <https://clicktime.symantec.com/a/1/VD92eMlNQNYWvTHMFGJ6d9CoI8TWzptcPQ9N_WgcsEc=?d=BGAdaOmUwTeTJGDCY0PxccF0_w2aXYWPkZ7TqUaX5BfIwvuies1FpFGWK0a0V-ztU78uUhUTIHuntFNIacX_7R-N7h4qVswHza4R-xOhmPRaQu6xRDCjEZfI6H1_u4borbcUPyDQ6liK-yuculXq6ICDidJQPJtYEveno35W1lltgoNkAeIagO29GvgnsgoziKJ4U4zRUDXIZwQeuBXTC3NRd9iLtHz1IZhXsFCNmIC7QGkD278pz90U42sWT96yrGQLpPfsfpg05TFLkE_BGipWpMwKeLCYUqii7-0V9sOqCdVrNOfjC3Ruk9eeyMyFZS5pjXRNSNFElfHytB77QRZC87cWwM8aULV5KlIMMkmasWMWav7pb5xQc8VgqrXKzD2DtrP8F80Uyc48XqNNjuzvmT7TK7cDvvzhGtUvS4WXZfr-70e3-6fpQa4k&u=https%3A%2F%2Fllvm.org%2Fdocs%2FCodeGenerator.html%23mapping-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,…) ? > > > > > > [image: > 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 > <+32%204%20361%2081%2020> > 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. > ------------------------------------------------------------ > ------------------- > > ------------------------------------------------------------ > ------------------ > > 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 > >-- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180330/b6beba5f/attachment.html>
Krzysztof Parzyszek via llvm-dev
2018-Apr-02 14:59 UTC
[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://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
Dominique Torette via llvm-dev
2018-Apr-03 13:53 UTC
[llvm-dev] Mapping virtual registers to physical registers
Hi Krzysztof, Thanks for your response.
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-bounces at lists.llvm.org] On Behalf Of
Krzysztof Parzyszek via llvm-dev
Sent: lundi 2 avril 2018 17:00
To: llvm-dev at 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
>
> 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
> 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-dev at lists.llvm.org
https://clicktime.symantec.com/a/1/SkcUKSTguelZdoQ0cCShN0FUpnRosHtFjFV8WvXHfPg=?d=zjKiRR7eOkU7w-B6rd8m5DDFsuNq0PcW_s7qRxc5ku1F7yXxMJEw8ft1ExiCifu0BPMerFoBFrT1JAqrzo7iQxrqs4u5jTVZ2BrGfjOkKHlik8H1JTR3dPKAjd1x7qZu3sZ791xRJbzh2b5nJ0nESfPbU_raIgWS_KlIwv7CzR5jgqBC8_UjcS8INrg9DYAa91YEoBnkpMsR5nmwxOwHxrg94ARv15Jkau47BqHfowR2wmELfIzFjh_umT7Vkr9jI9c6qcXoXvYb5Kcvn9UXp5j4tOO58iozjnB9tHzCgUaZ6WKB8DV7xv6mS_2viUKUH6uVrHPT7rOBc6qTqLKQGnXVlZbRYkPIMz4nXqAE_hx5OTnCQuchlvSGaegNVz_YFL-j9TwL6mwpTBgzOcmlem_TfEo1SyMKgZDQ6UntyqHr_2Z1UA%3D%3D&u=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev
------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------