LGTM, thanks!

Use member function.

LGTM, thanks!

I like the general approach. It seems like things could get unwieldy with larger SchedGroups. You would need to have lots of checks vs Collection.size() which could be somewhat hard to work with.

Added AMDGPU group to reviewers.

Update tests.

Actually, this is breaking tests with non-HSA. Is TargetID relevant for pal/graphics/ect @foad, or should the default there be XNACK- in the absence of any explicit subtarget features being added?

Add readelf run-line to test.

LGTM, can you renumber regs in the test please.

Didn't this land?

LGTM.

Can you add some debug printouts so we know when this is being triggered in logs?

LGTM

LGTM, thanks!

I think this makes sense, but it also makes the concept of an occupancy target a misnomer.

Is it possible to just check for cumode? I don't really have a problem with this since on Navi we can't really take advantage of barriers being too conservative without addrspace info on fences, but it really only has an impact when compiling for cumode. Also, I thought the workaround was pretty simple.

In D139227#3980133, @jrbyrnes wrote:

Hi Austin,

Changes look fine -- and if experiments show it has better performance then I suppose it is better. But the pipeline seems rather arbitrary -- in fact, in the test the previous pipeline fits the requirements of the new one. Maybe since the DAG is less constrained the scheduler has a better ability to produce improved schedule?

Also, having pipeline with 3x as many MFMA SchedGroups as there are MFMAs is an impossible pipeline. I assume you also tried I < MFMACount ?

Interesting. Why exactly does this improve compile time so much? I thought reverting scheduling wasn't exactly expensive and the RP tracking was the problem.

In D135733#3855154, @foad wrote:

Could you detect empty inline asms and do this only for the non-empty ones? In graphics we use empty inline asms as some kind of scheduling barrier. (Granted this is just a workaround for problems elsewhere, but I don't really want it broken or penalised just now.)

LGTM

LGTM

Address comments.

Don't loop over all instructions again in pre-RA scheduler.

Address comment.

Update pipeline, remove edges from iglp_opt.

LGTM

In D131022#3695204, @rampitec wrote:

I do not follow, what's the difference in passing -mllvm -misched vs -mllvm -another-option?

Address comments.

In D130869#3691259, @foad wrote:

Is scheduling for maximum ILP the same thing as scheduling for minimum latency?

Thanks! I like the idea behind the greedy solver. Not sure about SchedGroupSU. Maybe just a map between SUs and lists of schedgroups? I think trying to track sched_group_barriers by their order and assigning that an index is a bit confusing.

In D130722#3685771, @rampitec wrote:

What's the resolution of mesa problem?

Resubmit https://reviews.llvm.org/D120544.

In D130654#3683352, @kerbowa wrote:

Why not make it a scheduling boundary?

Why not make it a scheduling boundary?

Fix not running unclustred pass on non-excess RP regions.

Minor fixes.

Fix some bugs. Add better pipeline fitting. Address comments.

I'm not objecting to the change, just pointing out that you may miss out on some optimization since this is lowered to inline ASM, and that you may want to lower it to intrinsics in the future.

Can you add a test with the bug?

In D129522#3643798, @krzysz00 wrote:

This is a single op that expands to both a waitcnt on LDS and a barrier. I
can go digging tomorrow for what we used to lower this to some sort of
fence and a barrier, but I recall ( @whchung who may have more detail) that
using this bit of inline assembly to work around what I think was the lack
of an LDS-only fence gave a noticable performance increase

Is this really necessary if we have https://reviews.llvm.org/D120544. A barrier has no requirement to wait for LDS and VMEM it only does so currently because of a bug. Using inline asm like this seems like it will eventually cause problems although I'm not too familiar with MLIR.

Can we not rename initCandidate since it is mimicking GenericScheduler::initCandidate?