Displaying 4 results from an estimated 4 matches for "postramachinelicm".
2016 Jan 13
2
Allowing virtual registers after register allocation
...ffects
of disabling them, etc.
Currently the following target-independent passes run after register
allocation (ordered and categorized according to how they appear in
lib/CodeGen/Passes.cpp):
OptimizedRegAlloc: (run only if there is a RegAllocPass, which is not true
for wasm)
StackSlotColoring
PostRAMachineLICM
ShrinkWrap
PrologEpilogInserter
Machine late optimization:
BranchFolderPass
TailDuplicate
MachineCopyPropagation
PostRAScheduler
ExpandPostRAPseudos
ImplicitNullChecks (optional)
PostMachineScheduler or PostRAScheduler
GC:
GCMachineCodeAnalysis
GC info printer
Block Placement:
MachineBlockPl...
2016 Jan 22
2
Allowing virtual registers after register allocation
...rrently the following target-independent passes run after register
> allocation (ordered and categorized according to how they appear in
> lib/CodeGen/Passes.cpp):
>
> OptimizedRegAlloc: (run only if there is a RegAllocPass, which is not true
> for wasm)
> StackSlotColoring
> PostRAMachineLICM
> ShrinkWrap
> PrologEpilogInserter
> Machine late optimization:
> BranchFolderPass
> TailDuplicate
> MachineCopyPropagation
> PostRAScheduler
> ExpandPostRAPseudos
> ImplicitNullChecks (optional)
> PostMachineScheduler or PostRAScheduler
> GC:
> GCMachineCo...
2016 Jan 22
2
Allowing virtual registers after register allocation
...ing target-independent passes run after register allocation (ordered and categorized according to how they appear in lib/CodeGen/Passes.cpp):
>>>
>>> OptimizedRegAlloc: (run only if there is a RegAllocPass, which is not true for wasm)
>>> StackSlotColoring
>>> PostRAMachineLICM
>>> ShrinkWrap
>>> PrologEpilogInserter
>>> Machine late optimization:
>>> BranchFolderPass
>>> TailDuplicate
>>> MachineCopyPropagation
>>> PostRAScheduler
>>> ExpandPostRAPseudos
>>> ImplicitNullChecks (optional)...
2015 Dec 10
3
Allowing virtual registers after register allocation
To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way.
Problems when using virtregs throughout the backend until emit time:
- The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs
- VirtRegs are assumed to have a definition,