[llvm-dev] Mapping virtual registers to physical registers
Krzysztof Parzyszek via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 3 07:18:26 PDT 2018
Hi Dominique,
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
On 4/3/2018 8:53 AM, Dominique Torette via llvm-dev wrote:
> 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.
> -------------------------------------------------------------------------------
> _______________________________________________
> 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