[llvm-commits] [PATCH] DAG post-process for Hexagon MI scheduler

[Sergei Larin]

Sure. Makes perfect sense.

Nevertheless, I am not totally done with "custom" functions just yet... Let
me a bit more time to make use of this hook, and see if I will need yet
another one.

Thanks.

Sergei

---
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation


> -----Original Message-----
> From: Andrew Trick [mailto:atrick at apple.com]
> Sent: Friday, September 14, 2012 12:29 PM
> To: Sergei Larin
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm-commits] [PATCH] DAG post-process for Hexagon MI
> scheduler
> 
> 
> On Sep 13, 2012, at 3:44 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> >
> > On Sep 13, 2012, at 3:29 PM, Sergei Larin <slarin at codeaurora.org>
> wrote:
> >
> >> Hello Andy, Hello everyone,
> >>
> >> This patch introduces a possibility for Hexagon MI scheduler to
> >> perform some target specific post- processing on the scheduling DAG
> >> prior to scheduling.
> >>
> >> - Currently it only enforces one kind of scheduling hazard, but
> could
> >> be extended in the future
> >> - it only modifies Hexagon back end
> >> - it passes make check-all
> >>
> >> As a general idea - this is a fast and simple way to enforce some
> >> scheduling rules that are awkward to enforce in any other way - like
> >> one kind of instruction not to bypass another one while there are no
> >> dependencies or hw hazards between them. It is conceptually
> different
> >> from DFA and not easily doable with HazardRecognizer. If the idea is
> >> applicable to any other back end, maybe a common interface to
> >> MachineSchedStrategy would be practical.
> >
> > LGTM. Go ahead and checkin.
> >
> > I like the idea of initializing MachineSchedStrategy only after the
> DAG is ready to be scheduled. So this is a good example of when you
> should subclass and extend ScheduleDAGMI (before now you really didn't
> need to do that). Since post-processing the DAG is such an obvious
> thing for a Target to do, I'll add a virtual call in ScheduleDAGMI so
> it can be done without overriding the driver.
> 
> I added a hook that does not require subclassing ScheduleDAGMI
> (r163915), since enough of the ScheduleDAG interface is public, and
> "expected" customization should not require subclassing.
> 
> It would be nice if you use this hook for consistency. It should
> obviate the ScheduleDAGVLIW, but you may still want your own DAG
> subclass later anyway.
> 
> -Andy