Add TODO for debug instructions and rebase.

Address Arsenault's comments.

LGTM. Pls wait for 1 or 2 days in case there are comments from other reviewers.

Address Arsenault's comments.

This patch is to fix the global ISel issue encountered in D126771 and http://45.33.8.238/macm1/37938/step_11.txt.

I create a patch (D129037) to fix the global ISel issue.

Address Xiang's comments.

@nikic , could you help to check if this patch can fix the regression caused by D128584?

@nikic , could you help to check if D128804 can fix the regression?

In D128584#3618128, @LuoYuanke wrote:

In D128584#3618012, @nikic wrote:

It looks like this change had some compile-time impact: http://llvm-compile-time-tracker.com/compare.php?from=fc2d96c334a15d00965eb57a99d49e46728641db&to=5cb09798700aecff1f9f61b7cd80852c61e10fa8&stat=instructions I wonder whether there is any easy way to avoid the overhead if tile registers are not used?

We check the ShouldAllocateClass() in RegAllocBase::enqueue(). The overhead looks small because in the first GreedyRA pass most vritual register is not enqueued yet, but it seems I was wrong. I notice the regession is in O3 build, let me check if any more passes are added unexpectedly in O3

In D128584#3618012, @nikic wrote:

It looks like this change had some compile-time impact: http://llvm-compile-time-tracker.com/compare.php?from=fc2d96c334a15d00965eb57a99d49e46728641db&to=5cb09798700aecff1f9f61b7cd80852c61e10fa8&stat=instructions I wonder whether there is any easy way to avoid the overhead if tile registers are not used?

I can duplicated the regression with "llc -mtriple=aarch64 test/DebugInfo/Generic/two-cus-from-same-file.ll -O2 -o -". This is a ISel bug on "DBG_VALUE", I'll file a bug for it.

In D128584#3614128, @xiangzhangllvm wrote:

I think the spill/split should still cover the shape regs:

Let me first simply remember our previous action about greedy allocation for AMX:

1 We collected shapes (MOs) in allocating tile regs (by hint tile for same shape) in greedy
2 After greedy we insert the "fill" instructions to set the shape to ldtilecfg's mem. (They are still virtual)
3 Then the rewriter assign to physic regs to them.

The order of related passes:

Greedy Register Allocator
Verify generated machine code
Tile Register Configure
Verify generated machine code
Virtual Register Rewriter
Verify generated machine code
Register Allocation Pass Scoring

Example: After Tile Register Configure

96B       VMOVUPSZmr %stack.0, 1, $noreg, 0, $noreg, %13:vr512 :: (store (s512) into %stack.0, align 4)
104B      MOV8mi %stack.0, 1, $noreg, 0, $noreg, 1 :: (store (s512) into %stack.0, align 4)
112B      MOV16mi %stack.0, 1, $noreg, 18, $noreg, 8 :: (store (s512) into %stack.0 + 18, align 2, basealign 4)
116B      MOV8mi %stack.0, 1, $noreg, 50, $noreg, 8 :: (store (s512) into %stack.0 + 50, align 2, basealign 4)
124B      MOV16mr %stack.0, 1, $noreg, 20, $noreg, %1.sub_16bit:gr32 :: (store (s512) into %stack.0 + 20, align 4)
132B      MOV8mr %stack.0, 1, $noreg, 49, $noreg, %0.sub_8bit:gr32 :: (store (s512) into %stack.0 + 49, align 1, basealign 4)
140B      MOV16mr %stack.0, 1, $noreg, 16, $noreg, %1.sub_16bit:gr32 :: (store (s512) into %stack.0 + 16, align 4)
148B      MOV8mr %stack.0, 1, $noreg, 48, $noreg, %0.sub_8bit:gr32 :: (store (s512) into %stack.0 + 48, align 4)
172B      PLDTILECFGV %stack.0, 1, $noreg, 0, $noreg, implicit-def dead $tmm0,  xxx

Fix typo.

I create a patch at https://reviews.llvm.org/D128437.

I was able to duplicate this issue with --global-isel. I'll come up with a patch to fix it.

In D126771#3604703, @DavidSpickett wrote:

I also bisected an lldb failure down to this: https://lab.llvm.org/buildbot/#/builders/96/builds/25038/steps/6/logs/stdio

It has backtrace of a sort but it's probably not much help, I will get hold of the reproducer files.

In D126771#3604566, @thakis wrote:

This also broke check-llvm on macOS: http://45.33.8.238/macm1/37938/step_11.txt (this both is an M1 mac, not sure if intel vs arm matter).

Please take a look at that too, and revert for now if it takes a while to fix.

(This failure was masked by the check-clang failure. But I locally bisected and verified that it's due to this change, and that locally reverting fixes the check-llvm failure.)

LGTM, except minor format issue. Thanks, @nikic

In D126771#3604306, @thakis wrote:

On many of the official bots too, eg https://lab.llvm.org/buildbot/#/builders/109/builds/41178 (did that not generate an email?)

Removed the change of X86 test case.

Remove X86 related code.

Add test case to stop after fast RA.

@arsenm , could you take a look at the AMDGPU test case?

Fix AMDGPU test case failure.

Rebase

Address Xiang's comments and add a test case to clobber tmm register.

In D127848#3585723, @MatzeB wrote:

I see this code in the MachineVerifier:

} else if (MRI->def_empty(Reg)) {
  report("Reading virtual register without a def", MO, MONum);

Which reads to me that we do not allow virtual registers without a definition if there is at least 1 read of the register. But I guess that means you can indeed have a vreg without a def if all the uses are marked undef or are debug operands or similar situations where MO.readsReg() is false.

In D127848#3585696, @MatzeB wrote:

I'm also not sure right now if vregs without definitions are even legal MIR while we are still in MachineSSA... Checking that now

Thanks @shchenz for review. Let me land this patch first and we can improve the code later.

In D126771#3576818, @xiangzhangllvm wrote:

I think the idea of "split" special registers RA pass is good (especially for the registers who need to be config).
I notice all the "isVirtual<Register>" places need carefully to "exclude" the special registers.
Seems we may no need to do it if we can make sure that we handle these special registers before normal fast RA.
(because they have be allocated to physic registers)

ping

LGTM, thanks.

In D126771#3549988, @arsenm wrote:

I thought I implemented this before. We do need to add some AMDGPU tests for this. @cdevadas recently noticed this was broken

In D125602#3547595, @MatzeB wrote:

There's a lot going on here.

• Could you extract the ShouldAllocClass fixes for fastregalloc into a separate diff so we can get discuss them separately and get feedback from AMDGPU folks who introduced this and are the major other user of this AFAIK.

Add test case across config.

Add test case for reuse physical tile register.