search for: gcmachinecodeanalysis

...ly 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 registe...

> 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

Hi Chris, Chris Lattner wrote: > You haven't missed anything, there isn't currently a way to do this. > Good to know. Anything against making the codegen pass manager accessible to users? Something like ExecutionEngine::getCommonCodegenPassManager() ? Thanks, Nicolas

On Sep 15, 2009, at 12:00 AM, Nicolas Geoffray wrote: > Hi Chris, > > Chris Lattner wrote: >> You haven't missed anything, there isn't currently a way to do this. >> > > Good to know. Anything against making the codegen pass manager > accessible to users? Something like > ExecutionEngine::getCommonCodegenPassManager() ? I don't have a problem with

...Pass, 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: 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: PostRAMachineLIC...

...MachineLICM > ShrinkWrap > PrologEpilogInserter > Machine late optimization: > 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. > > > H...

...the collector. The JIT/runtime can parse LLVM's stack map data and encode it using it's own data structures. That way, the JIT/runtime can change without customizing LLVM. As far as hooking the new stack map support into the GCMetaData abstraction, I'm not sure how that would work. GCMachineCodeAnalysis is currently a standalone MI pass. We can't generate our stack maps here. Technically, a preEmitPass can come along later and reassign registers invalidating the stack map. That's why we generate the maps during MC lowering. So, currently, the new intrinsics are serving a different purpose...

...untime can parse LLVM's stack map data > and encode it using it's own data structures. That way, the > JIT/runtime can change without customizing LLVM. > > As far as hooking the new stack map support into the GCMetaData > abstraction, I'm not sure how that would work. GCMachineCodeAnalysis > is currently a standalone MI pass. We can't generate our stack maps > here. Technically, a preEmitPass can come along later and reassign > registers invalidating the stack map. That's why we generate the maps > during MC lowering. > > So, currently, the new intrinsics ar...

Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support came from, I wanted to draw this conversation to the attention of someone more familiar with the LLVM implementation than myself. On 10/22/13 4:18 PM, Andrew Trick wrote: > On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com > <mailto:fpizlo

...optimization: >>> 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) wou...

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,