Replaced MI.readsWritesVirtualRegister(Reg).first with readsVirtualRegister.

• Rebased.
• Added tests.

Got some test failure on graphics, fixing.

Update failed expensive checks llc-pipeline.ll test.

Disable pass for CodeGen/AMDGPU/dead-lane.mir test.

Rebase before landing.

ping.

Improved function description.

Fixed llc-pipeline test, rebased.

Rebase.

• Rebased.
• Minor issues fixed.

In D149775#4364811, @crobeck wrote:

In D149775#4338257, @vpykhtin wrote:

What if we always reserve a register for long jumps?

I think we still want the ability to not reserve them in cases where they might not actually be needed and would waste resources. The amdgpu-long-branch-factor initialized default has been reset higher so that we lean toward always reserving them now - if this value is 0 the long branch registers are never reserved. As this value grows the great chance the branch distance will fall within the threshold and the registers will be marked to be reserved.

What if we always reserve a register for long jumps?

I'm not sure why but this review doesn't contain context (unchanged lines of code), may be it worth to try arc diff to generate review requests.

ping.

Ok, since this isn't critical I don't have strong preference to erase by the iterator, I'm fine with shorter and nicer version with make_early_inc_range :) Thank you :)

• Rebased, updated tests.
• Added debug operand processing with a TODO, added test.

LGTM, thank you!

Rebased before landing.

I tried this patch again a final time, this time passing the RegInfo pointer to removeRedundantDef() and further into clearKillsForDef(). My idea here is that this would only mean a single lookup for both the def and the kill. This was however also not any faster at all.

I also tried having a vector of RegInfo:s for each MBB - instead of a map. The idea was to make the lookup time linear, but this was much slower in small functions (while perhaps good idea in huge ones).

I have tried different map types before, so I don't think there is anything to gain from that.

I will post my patch as a separate review...

• Rebased, updated lit tests.
• Per review issues partially done.

If the map lookup time really matters, maybe it could be worth trying a vector of DefMI/KillMI pairs, so lookup time would be O(n) into the vector..?

I don't think it's that critical

ping.

• Rebased.

On SystemZ, the two versions show practically identical runtimes, so there is no winner. Is there any difference at all on your machine?

Not really :) Something barely measurable like 2.13 and 2.09 seconds on the huge testcase. I'm curious which cases you use to compare to the current, non-map version?

Fixed debug build.

Mine version of the patch.

Going to reclaim this work

Per review issues:

• Improved comments.
• More C++ structure bingind syntax used.

Tried version with LiveIntervalUnion but it works slightly slower than first:

~4.2 vs ~3 seconds per pass on my testcase.

• Improved comments.
• Rebased, updated tests.

In D146057#4193602, @MatzeB wrote:

Hmm the main RAGreedy allocator is using the LiveRegMatrix and within that the LiveIntervalUnion classes to keep things performant. Maybe we can use those here too? In principle they should have even better runtime behavior than merging here...

• fixed typo, debug build, added comment.

Unfortunatelly stack growed x180 times with slot sharing disabled, so this isn't an option.

Hi Valery, thanks for the report! It would be nice if you posted your test case on github issues and assigned me (and/or yourself :)... I would think this could be fixed.

ping

Makes sense to me - I tried also earlier to store the kills in a map but I found (at least on SystemZ) that this backwards search was actually quicker than that, so I don't think it should be an issue in the normal case...

• added generated checks.

• added regression test.
• rebased after the fix a999669982d0: [AMDGPU] Scheduler: fix RP calculation for a MBB with one successor

• rebased.
• added comment.

ping

This patch depends on https://reviews.llvm.org/D136918 fix.

I would like to reclaim this but with different reasoning:

Kindly pinging, this is ready to submit.

• Rebased.
• Improved interval updating code.
• Passed internal testing.

• Rebased.
• Removed ad-hoc in-place interval modification, replaced with copy.

• Rebased.
• Passed internal testing.

Forgot to remove disabled code, done.