[llvm-dev] Allowing virtual registers after register allocation

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Quentin Colombet" <qcolombet at apple.com>
> To: "Derek Schuff" <dschuff at google.com>
> Cc: "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org
> Sent: Thursday, December 10, 2015 1:11:19 PM
> Subject: Re: [llvm-dev] Allowing virtual registers after register allocation
> 
> On Dec 10, 2015, at 10:49 AM, Derek Schuff < dschuff at google.com >
> wrote:
> 
> On Thu, Dec 10, 2015 at 10:13 AM Quentin Colombet <
> qcolombet at apple.com > wrote:
> 
> I am tempted to think no, we don’t, but I don’t know the use cases.
> What post-RA passes with want to run with virtual regs?
> 
> 
> The immediate one that precipitated this mail was
> PrologEpilogInserter.
> However currently the only other pass we have disabled in
> WebAssemblyTargetMachine is MachineCopyPropagation.
> Several passes (post-RA MachineLICM, StackSlotColoring) already only
> run if RA runs.
> Everything else is running today. Currently that's ShrinkWrap,
> BranchFolder, ExpandPostRAPseudos, PostRAScheduler,
> GCMachineCodeAnalysis, MachineBlockPlacement, FuncletLayout, and
> StackMapLiveness. All of these run after our register coloring pass.
> 
> 
> I don’t know for the other passes, but I don’t think it makes sense
> to teach PrologEpilogInserter to work on virtual registers, since
> part of its job is to get rid of any virtual registers created when
> lowering the frame.
> I.e., that would indirectly mean that we would need to teach the
> scavenger how to recycle virtual registers!
> 

I think this is exactly the part of PEI that they disable.

 -Hal

> 
> The bottom line is, it feels wrong to me.
> 
> 
> Cheers,
> Q.

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory