similar to: top-down vs. bottom-up list scheduling

> On Oct 13, 2017, at 1:46 PM, Matthias Braun <matze at braunis.de> wrote: > > Yes, I've run into the problem myself that the Pending queue isn't even checked with the tryCandidate() logic and so takes priority over all other scheduling decisions. > > I personally would be open to changes in this area. To start the brainstorming I could imagine that we move nodes

Hi Andy, Thanks for the explanations. Yes AMDGPU is in-order and has MicroOpBufferSize = 1. Re "issue limited" and instruction groups: could it make sense to disable the generic scheduler's detection of issue limitation on in-order CPUs, or on CPUs that don't define instruction groups, or some similar condition? Something like: --- a/lib/CodeGen/MachineScheduler.cpp +++

Hi, I have been experimenting for a while with tryCandidate() method of the pre-RA mischeduler. I have by chance found some parameters that give quite good results on benchmarks on SystemZ (on average 1% improvement, some improvements of several percent and very little regressions). Basically, I add a "latency heuristic boost" just above processor resources checking:

Hi, I've been looking at the Machine Scheduler on Power PC. I am looking only at the pre-RA machine scheduler and I am running it in the default bi-directional mode (so, both top down and bottom up queues are considered). I've come across an example where the scheduler picks a poor ordering for the instructions which results in very high register pressure which results in spills.

Hi, I'm trying to understand why MachineScheduler does a poor job in straight line code in cases like the one in the attached debug dump. This is on AMDGPU, an in-order target, and the problem is that the IMAGE_SAMPLE instructions have very high (80 cycle) latency, but in the resulting schedule they are often placed right next to their uses like this: 1784B %140:vgpr_32 =

On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: Now, to generate the best PPC schedules, there is one thing you may > want to override. The scheduler's priority function has a > HasReadyFilter attribute (enum). It can be overriden by specializing > hybrid_ls_rr_sort. Setting this to "true" enables proper ILP > scheduling, and maximizes the instructions that can

On Mon, 2011-12-19 at 07:41 -0800, Andrew Trick wrote: > On Dec 19, 2011, at 6:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > > Now, to generate the best PPC schedules, there is one thing you may > >> want to override. The scheduler's priority function has a > >> HasReadyFilter attribute

On Dec 19, 2011, at 6:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: > On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > Now, to generate the best PPC schedules, there is one thing you may >> want to override. The scheduler's priority function has a >> HasReadyFilter attribute (enum). It can be overriden by specializing >> hybrid_ls_rr_sort. Setting this to

Is there documentation somewhere for the bottom-up scheduling? I'm trying to figure out what changes are necessary in order to support it in the PPC backend. Thanks in advance, Hal On Thu, 2011-10-20 at 10:21 -0700, Evan Cheng wrote: > > On Oct 19, 2011, at 7:29 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > Evan, > > > > Thanks for the heads up! Is

On Dec 19, 2011, at 3:19 PM, Hal Finkel wrote: > On Mon, 2011-12-19 at 07:41 -0800, Andrew Trick wrote: >> On Dec 19, 2011, at 6:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: >>> Now, to generate the best PPC schedules, there is one thing you may >>>> want to override. The

On Oct 25, 2011, at 6:01 PM, Hal Finkel wrote: > Is there documentation somewhere for the bottom-up scheduling? I'm > trying to figure out what changes are necessary in order to support it > in the PPC backend. > > Thanks in advance, > Hal > > On Thu, 2011-10-20 at 10:21 -0700, Evan Cheng wrote: >> >> On Oct 19, 2011, at 7:29 PM, Hal Finkel <hfinkel at

On Mon, 2011-12-19 at 22:14 -0800, Andrew Trick wrote: > On Dec 19, 2011, at 3:19 PM, Hal Finkel wrote: > > > On Mon, 2011-12-19 at 07:41 -0800, Andrew Trick wrote: > >> On Dec 19, 2011, at 6:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> > >>> On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > >>> Now, to generate the best

On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > On Oct 25, 2011, at 6:01 PM, Hal Finkel wrote: > > Is there documentation somewhere for the bottom-up scheduling? I'm > > trying to figure out what changes are necessary in order to support it > > in the PPC backend. > > > > Thanks in advance, > > Hal > > > > On Thu, 2011-10-20 at

> > Of course, you want to duplicate as little of the generic scheduling logic > as you can. So I think the challenge is how to expose the > generic scheduler's functionality as a base class or composition of > utilities so that defining your strategy doesn't require too much > copy-paste. ​Isn't GCNMaxOccupancySchedStrategy [1] already an example on using

On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > Here's my "thought experiment" (from PR11589): I have a bunch of > load-fadd-store chains to schedule. A store takes two cycles to clear > its last pipeline stage. The fadd takes longer to compute its result > (say 5 cycles), but can sustain a rate of 1 independent add per cycle. > As the scheduling is bottom-up, it

Hello. Is there a way to specify in the back end an (ISD::INLINEASM) SDNode to be scheduled first under all circumstances? I need to specify something like node priority to schedule the node before all other nodes in the SelectionDAG of the basic block. (Using chain or glue edges in order to make a node first is not a good idea, since I am doing this at instruction selection time, on

I probably misunderstood the question. You probably want to do this in SelectionDAG. On Fri, Oct 21, 2016 at 10:29 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > You can do this by changing instruction scheduling heuristics. I think the > more important question is if this correct always for all platforms. > > I don't know which scheduler you use. We use

Hi Sjoerd, On Fri, May 3, 2019 at 8:19 AM Sjoerd Meijer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I read that out-of-order cores are supported. How about in-order cores? > Would it be easy/difficult to add support for that? > > Cheers, > Sjoerd. > > I don't think that it would be difficult to support in-order superscalar cores. However, it would

On Thu, Jun 18, 2020 at 3:37 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > We’re talking about verbose output right? Verbose isn’t the default. > I'm fairly certain the issue in this thread is just the verbosity of -dump-input=fail. Yes, -vv makes it even more verbose by annotating input lines with good matches, etc., but that's not part of the "new

Sorry if I wasn't clear about my use case. In my daily dev work, I do many local "ninja check"s, or "llvm-lit" on a subdirectory as a quick(er) smoke test if I am making changes in that area (e.g. "llvm-lit ../llvm/test/CodeGen"). Nothing wrong here, as indeed nothing changed here. But in case of a test failure, I want to run just that test: bin/llvm-lit