similar to: [LLVMdev] Scheduler Roadmap

On May 8, 2012, at 3:02 PM, dag at cray.com wrote: > Hi everyone, > > As I've mentioned before we are doing some work on the LLVM scheduler to > improve it. Specifically, we are working to get loads and stores to > move past each other when possible. > > When I asked about enhancing scheduler heuristics a month or so ago, I > got a response about a MachineInstr

Andrew Trick <atrick at apple.com> writes: >> When I asked about enhancing scheduler heuristics a month or so ago, I >> got a response about a MachineInstr scheduler and that that was the way >> of the LLVM future. Is that so? Is the ScheduleDAG going away? > > You sent a lengthy RFC on Apr 20 that demonstrated you aren't > following developments on trunk.

On May 9, 2012, at 8:34 AM, dag at cray.com wrote: > Andrew Trick <atrick at apple.com> writes: > >>> When I asked about enhancing scheduler heuristics a month or so ago, I >>> got a response about a MachineInstr scheduler and that that was the way >>> of the LLVM future. Is that so? Is the ScheduleDAG going away? >> >> You sent a lengthy RFC

On May 9, 2012, at 8:34 AM, dag at cray.com wrote: > Andrew Trick <atrick at apple.com> writes: > >>> When I asked about enhancing scheduler heuristics a month or so ago, I >>> got a response about a MachineInstr scheduler and that that was the way >>> of the LLVM future. Is that so? Is the ScheduleDAG going away? >> >> You sent a lengthy RFC

On Thu, 10 May 2012 20:33:53 -0700 Andrew Trick <atrick at apple.com> wrote: > On May 9, 2012, at 8:34 AM, dag at cray.com wrote: > > > Andrew Trick <atrick at apple.com> writes: > > > >>> When I asked about enhancing scheduler heuristics a month or so > >>> ago, I got a response about a MachineInstr scheduler and that > >>> that

Andrew Trick <atrick at apple.com> writes: > We plan to move to the MachineScheduler by 3.2. The structure is: How hard will this be to backport to 3.1? Has woprk on this started yet? > ScheduleDAG: Abstract DAG of SUnits and SDeps > | > v > ScheduleDAGInstrs: Build the DAG from MachineInstrs, each SUnit tied to an MI > Delimit the current

On Apr 20, 2012, at 10:31 AM, dag at cray.com wrote: > I'd like to begin a project to rework the scheduler to address some > problems we've discovered on this end. The goal is to get a more > configurable/flexible scheduler while simplifying maintenance by > separating policy from implementation to get independent and > interchangeable parts. > > This is going to be

On Apr 24, 2012, at 8:59 AM, dag at cray.com wrote: > Andrew Trick <atrick at apple.com> writes: > >> We plan to move to the MachineScheduler by 3.2. The structure is: > > How hard will this be to backport to 3.1? Has woprk on this started > yet? In my previous message I outlined the steps that I would take to bring up the new scheduler. I'm about to checkin the

Jim Grosbach <grosbach at apple.com> writes: >> - How difficult do you expect a backport to 3.1 to be? We have to work >> from 3.1. Trunk is too buggy. > You've stated that trunk is too buggy for you to work from on multiple > occasions. Can you elaborate? That doesn't match my experience, as I > install a new compiler on my workstation from a trunk build

Hal Finkel <hfinkel at anl.gov> writes: >> Actually, we don't have any problem releasing tests. We have done so >> before when sending patches. The problem is the people we got the >> tests from. Some are from proprietary test suites, others are from >> sensitive codes, etc. It's often not up to us at all. > > I completely understand. Why don't

Andrew Trick <atrick at apple.com> writes: >> Ok, but that doesn't answer the question. Is SchedulerDAG going away? >> If so, what's the timeframe for that? 3.2? > > SchedulerDAG is used for both SD scheduling and MI scheduling. It's not going away. Oh! That's good news! > SD scheduling is not going away in 3.2--it will be the first release with MI

On May 10, 2012, at 9:06 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> - Target pass configuration: DONE >> - MachineScheduler pass framework: DONE >> - MI Scheduling DAG: DONE >> - AliasAnalysis aware DAG option: In review (Sergei) >> - Bidirectional list scheduling: DONE >> - LiveInterval Update: WIP (simple instruction reordering is >> supported)

On Jun 13, 2007, at 10:50 AM, Chris Lattner wrote: > On Tue, 12 Jun 2007, Christopher Lamb wrote: >>>>>> When should subregs be flattened to actual registers: >>>>>> AsmPrinter? >>>>>> Somewhere in LiveIntervals, during RegAlloc? >>> >>> This should definitely be done during regalloc. >> >> It seems that

Hey Everyone, I'd like to begin a project to rework the scheduler to address some problems we've discovered on this end. The goal is to get a more configurable/flexible scheduler while simplifying maintenance by separating policy from implementation to get independent and interchangeable parts. This is going to be challenging because we are still stuck on LLVM 2.9. We will be upgrading

My 2c... Even though I understand it might be way off in the future, but we are talking about long term plans here anyway. Also as a VLIW backend maintainer, I just have to say it :) - We do need to have a way to assign bundles much earlier than we do now. And it needs to be intertwined with scheduling (Bundler currently reuses a good chunk of scheduler infrastructure). It is also obvious

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're > misleading >

So if I use the SchedMachineModel method, can I just skip itineraries? Phil On Wed, Apr 20, 2016 at 12:29 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Target does make a difference. VLIW needs more hand-holding. For what you > are describing it should be fairly simple. > > > > Best strategy – see what other targets do. ARM might be a good start for > generic

On May 9, 2012, at 2:00 PM, dag at cray.com wrote: > Jim Grosbach <grosbach at apple.com> writes: > >>> - How difficult do you expect a backport to 3.1 to be? We have to work >>> from 3.1. Trunk is too buggy. > >> You've stated that trunk is too buggy for you to work from on multiple >> occasions. Can you elaborate? That doesn't match my

Sergei Larin <slarin at codeaurora.org> writes: > - We do need to have a way to assign bundles much earlier than we do now. Yeah, I can imagine why this would be useful. > And it needs to be intertwined with scheduling (Bundler currently reuses a > good chunk of scheduler infrastructure). Just to clarify, is the need due to the current bundling implementation of reusing

On Fri, 11 May 2012 10:26:41 -0500 <dag at cray.com> wrote: > Hal Finkel <hfinkel at anl.gov> writes: > > >> Actually, we don't have any problem releasing tests. We have done > >> so before when sending patches. The problem is the people we got > >> the tests from. Some are from proprietary test suites, others are > >> from sensitive