LGTM and we need some follow up patch to model the FPSCR and remove the hasSideEffects bit.

Address comments.

Address comments.

Gentle ping ...

Gentle ping ...

LGTM.

LGTM now.

LGTM.

LGTM. Thank you for doing this. I assume that you have run it with bmk to make sure that the functionality is fine.

Thank you Dave. Can someone from other target have a look at this refactor to see if there is any problems ?

LGTM and thank you for doing this. But please for a while to see if RKSimon has more comments.

https://reviews.llvm.org/D87614 is posted to fix this issue.

Simplify the logic and add tests. We still have cases that Peephole cannot handle due to missing the dependency information. But we don't want to handle it inside the scheduler as that is not right.

LGTM as far as you have verified the bmk, bootstrap with strict-fp enabled.

Gentle ping...

Add test.

LGTM.

Gentle ping...

I am a little surprised that, if virtual dispatch was hurting performance so much, function pointer would end up being a lot better. It's still a similar indirect non inlinable/optimisable function call.

Address reviewer's comments.

Abandon this PR as I want to merge this patch into the refactor patch.

Hello. This looks interesting. I've run into places before where we just wanted to add an extra heuristics. I think some of our downstream schedules go a bit beyond this and would still need to override tryCandidate (the merge is going to be a pain!), but I've run into situations where it would definitely be useful.

In D83937#2251316, @qiucf wrote:

define i32 @test(double %a, double %b) {
entry:
  %r = fcmp ogt double %a, %b
  %g = zext i1 %r to i32
  ret i32 %g
}

Print MIR:

renamable $cr0 = FCMPUD killed renamable $f1, killed renamable $f2 # Without mayRaise set
renamable $cr0 = nofpexcept FCMPUD killed renamable $f1, killed renamable $f2 # With mayRaise set

You can create a dedicated test file for fp-exception bit, so that we can re-check all fp-exception bits in instruction definitions.

Update tests.

Gentle ping ...

Confirm that no bmk deg found. Gentle ping ...

LGTM.

Reimplement with class instead of object for heuristics.

Update test.

In D86684#2241416, @foad wrote:

It is hard for target to add new heuristic now, as the Reason and tryCandidate() are maintained by base class.
It is hard for target to change the priority of each heuristic(i.e. prefer cluster over stall) as it is hard code by tryCandidate.

I agree. For the AMDGPU scheduler I am very interested in latency and register pressure, and not very interested in the other heuristics. I look forward to be being able to tweak this in the target sched strategy.

Address reviewer's comments.

Add helper macro to make the code more tidy and remove the tryGreater as it is not needed any more.

Gentle ping ...

LGTM now.

LGTM, thank you!

Add the reduce tests.

In D86183#2227988, @qiucf wrote:

The original test case is too big to get something useful. I happened to grab a basic block from it. It's not small enough to be a test, but it would be much easier to analyze: https://reviews.llvm.org/P8230

In D81924#2225652, @qiucf wrote:

In D81924#2189996, @steven.zhang wrote:

Can you add checker for the bdnz ?

We don't think any loop containing calls is profitable to transform:

Rebase the patch with pre-commit arch64 test and see more cluster pairs on one new AMDGPU test max.i16.ll

Gentle ping ...

Address comments.

I have proposed a new algorithm to do the memory cluster in D85517. Would you please verify if it can solve your problem ...

Fix typo ...

Fix typo.

Thank you for the review. I have added all the necessary comments in the test change to explain what happens inside. All works as expected from my view.

LGTM. But even we mark these two bif as boundary, there is still possible that, the pass after ISEL might move the MI across them. Some follow up work is needed to confirm this.