[llvm-dev] [regalloc] How to access the Virtual Registers Map?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] [regalloc] How to access the Virtual Registers Map?

Bruce Hoult via llvm-dev
Hi,

After Virtual Registers allocation, I would like to access and process the Registers Map assosiated to a function.
I'm interested to retreive the number of different physical registers required to map all the virtual registers.
(In the example here below, only two physical registers are required to map the 13 remaining virtual registers).

With "regalloc" debug option enabled, the following dump is produced by VirtRegRewriter::runOnMachineFunction()

 ********** REWRITE VIRTUAL REGISTERS **********
********** Function: _start
********** REGISTER MAP **********
[%vreg2 -> %FA_ROFF1] FPUaOffsetClass
[%vreg3 -> %FA_ROFF2] FPUaOffsetClass
[%vreg4 -> %FA_ROFF1] FPUaOffsetClass
[%vreg5 -> %FA_ROFF1] FPUaOffsetClass
[%vreg6 -> %FA_ROFF1] FPUaOffsetClass
[%vreg7 -> %FA_ROFF1] FPUaOffsetClass
[%vreg8 -> %FA_ROFF1] FPUaOffsetClass
[%vreg9 -> %FA_ROFF1] FPUaOffsetClass
[%vreg10 -> %FA_ROFF1] FPUaOffsetClass
[%vreg11 -> %FA_ROFF1] FPUaOffsetClass
[%vreg12 -> %FA_ROFF1] FPUaOffsetClass
[%vreg13 -> %FA_ROFF1] FPUaOffsetClass
[%vreg14 -> %FA_ROFF2] FPUaOffsetClass

To produce this dump, this function first call:
  VRM = &getAnalysis<VirtRegMap>();

But at the end of the same function, virtual registers allocation seems to be cleared:
  VRM->clearAllVirt();
  MRI->clearVirtRegs();

Is there any simple hook around the VirtRegRewriter to retreive and process this Register Map.
Any suggestions are welcome...

Regards, Dominique T.

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




 ------------------------------------------------------------------------------

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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [regalloc] How to access the Virtual Registers Map?

Bruce Hoult via llvm-dev
Hi Dominique,

If you want to access this map, you need to add your pass after
register allocation but before the VirtRegRewriter pass.
You have a target hook for that: addPreRewrite.

Cheers,
-Quentin

2018-06-05 2:37 GMT-07:00 Dominique Torette via llvm-dev
<[hidden email]>:

> Hi,
>
> After Virtual Registers allocation, I would like to access and process the Registers Map assosiated to a function.
> I'm interested to retreive the number of different physical registers required to map all the virtual registers.
> (In the example here below, only two physical registers are required to map the 13 remaining virtual registers).
>
> With "regalloc" debug option enabled, the following dump is produced by VirtRegRewriter::runOnMachineFunction()
>
>  ********** REWRITE VIRTUAL REGISTERS **********
> ********** Function: _start
> ********** REGISTER MAP **********
> [%vreg2 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg3 -> %FA_ROFF2] FPUaOffsetClass
> [%vreg4 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg5 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg6 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg7 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg8 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg9 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg10 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg11 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg12 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg13 -> %FA_ROFF1] FPUaOffsetClass
> [%vreg14 -> %FA_ROFF2] FPUaOffsetClass
>
> To produce this dump, this function first call:
>   VRM = &getAnalysis<VirtRegMap>();
>
> But at the end of the same function, virtual registers allocation seems to be cleared:
>   VRM->clearAllVirt();
>   MRI->clearVirtRegs();
>
> Is there any simple hook around the VirtRegRewriter to retreive and process this Register Map.
> Any suggestions are welcome...
>
> Regards, Dominique T.
>
> 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
>
>
>
>
>  ------------------------------------------------------------------------------
>
> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev