search for: postmachinescheduler

...sure if we can still do those book-keeping after RA. Talk about post-RA scheduler, I see there is another class PostRASchedulerList whose DEBUG_TYPE is post-RA-sched. I am wondering if that means we have two post-RA schedulers in LLVM right now? Any particular difference between those two classes, PostMachineScheduler and PostRASchedulerList? Thanks. Regards, chenwj 2017-04-25 10:46 GMT+08:00 Matthias Braun <mbraun at apple.com>: > >> On Apr 22, 2017, at 5:12 AM, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi All, >> >> The description of ScheduleDA...

Hi All, The description of ScheduleDAGMILive [1] says: ScheduleDAGMILive is an implementation of ScheduleDAGInstrs that schedules machine instructions while updating LiveIntervals and tracking regpressure. Does the live interval and register pressure part of ScheduleDAGMILive mean the subclass of ScheduleDAGMILive is a pre-RA scheduler? I assume the post-RA scheduler no need to take

Also you might need to check use PostRASchedulerList or PostMachineScheduler, PostRASchedulerList is considered deprecated as mentioned in [1]. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-April/112348.html HTH, chenwj 2017-06-10 4:03 GMT+08:00 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw>: > Not saying I am totally understand how thing works, but I think you'...

Hi All, While reading SchedulePostRATDList::ListScheduleTopDown() [1], I find SchedulingPriorityQueue::dump has an empty implementation. Therefore, the following debug dump basically outputs nothing. DEBUG(dbgs() << "\n*** Examining Available\n"; AvailableQueue.dump(this)); Not sure why we want this. Is it intended? [1]

Hello. I am using the post-RA (Register Allocation) scheduler to avoid data hazards by inserting other USEFUL instructions from the program (besides NOPs) and it breaks apart some sequences of instructions which should remain "glued" together. More exactly, in my [Target]ISelDAGToDAG.cpp it is possible that I replace for example a BUILD_VECTOR with a machine SDNode called

Hi, I have read the steps of code generation from here: The LLVM Target-Independent Code Generator — LLVM 3.8 documentation |   | |   | |   |   |   |   |   | | The LLVM Target-Independent Code Generator — LLVM 3...Instruction Selection Instruction Selection is the process of translating LLVM code presented to thecode generator into target-specific machine instructions. | | | | View on llvm.org

...zedRegAlloc: (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: MachineBlockPlacement MachineBlockPlacementStats FuncletLayout StackMapLiveness LiveDebugValues All of the pre-regalloc passes (and analyses) would just get marked as supporting virtual registers. Here are some not...

Hi All, I am trying to construct a small optimization based on ScheduleDAGInstrs that does the following: 1. Find candidate nodes in the DAG, and speculatively modify the node (nodes). 2. After modification, try to compute the scheduled cycles of the region. 3. If the cycle number improves, go back to 1. to find the next candidate node. I am thinking using

...rue > 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 marke...

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

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,