[llvm-dev] Implict output register allocation in two operands instructions set.

Dominique Torette via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 29 01:10:41 PDT 2017


Hi,

I'm implementing the registers allocation for Instructions Set where arithmetic operations only have two input explicit operands.
The result is always assigned to an implicit output register depending of the operation.

For example, the LADDS_A_oo operation has two inputs offset operands, but the output is FA_ROUTADD register.
            def                   LADDS_A_oo   : CLPFPU_A_oo<0b0000100001,
                                                (ins FPUaOffsetOperand:$OffsetA,FPUaOffsetOperand:$OffsetB),
                                                (outs FPUaROUTRegisterClass:$FA_ROUTADD),
                                                [FA_ROUTADD,RFLAGA],                                                         // list of implicit registers
                                                "ladds_a\t$OffsetA,$OffsetB",
                                                [(set i16:$FA_ROUTADD, (add i16:$OffsetA, i16:$OffsetB))],NoItinerary>;


A small code seems to be correctly lowered as follow.

Total amount of phi nodes to update: 0
*** MachineFunction at end of ISel ***
# Machine code for function add16_reg_reg: SSA
Function Live Ins: %FA_ROFF0 in %vreg0, %FA_ROFF1 in %vreg1

BB#0: derived from LLVM BB %0
    Live Ins: %FA_ROFF0 %FA_ROFF1
                %vreg1<def> = COPY %FA_ROFF1; FPUaOffsetClass:%vreg1
                %vreg0<def> = COPY %FA_ROFF0; FPUaOffsetClass:%vreg0
                %vreg2<def> = LADDS_A_oo %vreg0, %vreg1, %FA_ROUTADD<imp-def,dead>, %RFLAGA<imp-def,dead>; FPUaROUTRegisterClass:%vreg2 FPUaOffsetClass:%vreg0,%vreg1
                %FA_ROFF0<def> = COPY %vreg2; FPUaROUTRegisterClass:%vreg2
                %vreg3<def> = MOVSUTO_SU_os_rpc 0, %FA_ROFF0<imp-use>; SUSpecialRPCRegisterClass:%vreg3

# End machine code for function add16_reg_reg.

>From a register allocation point of view, this program will work only if vreg2 is allocated to the FA_ROUTADD register.
Is there a registers allocation pass that substitute the virtual register (vreg2) allocated to be assigned to the result of the operation with the physical one (FA_ROUTADD) where the result is assigned by the processor?
The physical register depend of the operations for additions it is FA_ROUTADD, but for division it is FA_ROUTDIV and multiplication it is FA_ROUTMUL?
Thanks,                Dominique Torette.





[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/20170829/a5554a9f/attachment.html>


More information about the llvm-dev mailing list