search for: stackmapliveness

...ss >> should run right before the "Assembly Printer" pass. >> Is there any official way to enforce this ? > > This makes sense and has come up before in discussions. I can envision a set of analyses that need to run after all MI modification but before asm printing. The StackMapLiveness pass is one such example. No enforcement mechanism exists yet, but it’s safe to say that nothing with modify MI after the addPreEmitPasses hook. For now you can just schedule your pass at the end with comments. > > We could introduce a fake MI analysis that should be invalidated by any pass...

Hi, I would like to execute a MachineFunctionPass after all other passes which modify the machine code. In other words, if we call llc to generate assembly file, that pass should run right before the "Assembly Printer" pass. Is there any official way to enforce this ? Best regards, Sebastien

...hineCopyPropagation. > 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 indirec...

...R. > > LivePhysRegs.stepBackward should be completely valid at any point, so if > there are bugs they need to be fixed. LivePhysRegs.stepForward is > conservative and relies on KILL flags so should only be used very early in > the MI pipeline for convenience as an optimization. > StackMapLivenessAnalysis uses stepBackward so should not depend on KILL > flags at all. LivePhysRegs should not modify any MI operands, so KILL flags > shouldn’t be getting “removed” by anything related to stackmaps or liveness. > > Note that we would like to move to a world where KILL flags are complet...

> On Dec 10, 2015, at 9:39 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > ----- 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: Wednesday, December

...mization: BranchFolderPass TailDuplicate MachineCopyPropagation PostRAScheduler ExpandPostRAPseudos ImplicitNullChecks (optional) PostMachineScheduler or PostRAScheduler GC: GCMachineCodeAnalysis GC info printer Block Placement: MachineBlockPlacement MachineBlockPlacementStats FuncletLayout StackMapLiveness LiveDebugValues All of the pre-regalloc passes (and analyses) would just get marked as supporting virtual registers. Here are some notes about passes of interest: PostRAMachineLICM (if not overriden by the target) is just the same MachineLICM which runs before regalloc and so handles vregs alre...

...gation > PostRAScheduler > ExpandPostRAPseudos > ImplicitNullChecks (optional) > PostMachineScheduler or PostRAScheduler > GC: > GCMachineCodeAnalysis > GC info printer > Block Placement: > MachineBlockPlacement > MachineBlockPlacementStats > FuncletLayout > StackMapLiveness > LiveDebugValues > > All of the pre-regalloc passes (and analyses) would just get marked as > supporting virtual registers. > > > Here are some notes about passes of interest: > > PostRAMachineLICM (if not overriden by the target) is just the same > MachineLICM which...

...hecks (optional) >>> PostMachineScheduler or PostRAScheduler >>> GC: >>> GCMachineCodeAnalysis >>> GC info printer >>> Block Placement: >>> MachineBlockPlacement >>> MachineBlockPlacementStats >>> FuncletLayout >>> StackMapLiveness >>> LiveDebugValues >>> >>> All of the pre-regalloc passes (and analyses) would just get marked as supporting virtual registers. >>> >>> >>> Here are some notes about passes of interest: >>> >>> PostRAMachineLICM (if not ov...

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,