[llvm-dev] Mapping virtual registers to physical registers
陳韋任 via llvm-dev
llvm-dev at lists.llvm.org
Fri Mar 30 07:39:44 PDT 2018
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>
More information about the llvm-dev
mailing list