VirtRegRewriter::rewrite(): Assertion `PhysReg.isValid() && "Invalid SubReg for physical register"' failed.

[zmodem]

We originally hit this building some PGO instrumented code for Android after a change to the SLP vectorizer; see #140279 (comment) for the original reproducer.

However, it seems the SLP change may just have uncovered a pre-existing backend problem.

To reproduce:

$ cat reduced.ll
target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7-unknown-linux-android29"

define void @_ZN11VersionEdit10DecodeFromEv(i1 %call4, ptr %__profc__ZN11VersionEdit10DecodeFromEv) {
land.rhs.lr.ph:
  br i1 %call4, label %sw.bb, label %while.cond.while.end_crit_edge.split.loop.exit43

while.cond.while.end_crit_edge.split.loop.exit43: ; preds = %land.rhs.lr.ph
  %0 = extractelement <4 x i64> zeroinitializer, i64 0
  br label %while.cond.while.end_crit_edge

while.cond.while.end_crit_edge:                   ; preds = %sw.bb, %while.cond.while.end_crit_edge.split.loop.exit43
  %pgocount5374.ph = phi i64 [ %2, %sw.bb ], [ %0, %while.cond.while.end_crit_edge.split.loop.exit43 ]
  %1 = insertelement <2 x i64> splat (i64 1), i64 %pgocount5374.ph, i64 1
  store <2 x i64> %1, ptr %__profc__ZN11VersionEdit10DecodeFromEv, align 8
  ret void

sw.bb:                                            ; preds = %land.rhs.lr.ph
  %2 = extractelement <4 x i64> splat (i64 1), i64 0
  br label %while.cond.while.end_crit_edge
}

$ build/bin/llc reduced.ll -o /dev/null
llc: /work/llvm-project/llvm/lib/CodeGen/VirtRegMap.cpp:733: void (anonymous namespace)::VirtRegRewriter::rewrite(): Assertion `PhysReg.isValid() && "Invalid SubReg for physical register"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
Stack dump:
0.      Program arguments: build/bin/llc reduced.ll -o /dev/null
1.      Running pass 'Function Pass Manager' on module 'reduced.ll'.
2.      Running pass 'Virtual Register Rewriter' on function '@_ZN11VersionEdit10DecodeFromEv'
 #0 0x000055a56814a5d8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build/bin/llc+0x232b5d8)
 #1 0x000055a568147d05 llvm::sys::RunSignalHandlers() (build/bin/llc+0x2328d05)
 #2 0x000055a56814b3f1 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 #3 0x00007f56e3647df0 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdf0)
 #4 0x00007f56e369c95c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #5 0x00007f56e3647cc2 raise ./signal/../sysdeps/posix/raise.c:27:6
 #6 0x00007f56e36304ac abort ./stdlib/abort.c:81:3
 #7 0x00007f56e3630420 __assert_perror_fail ./assert/assert-perr.c:31:1
 #8 0x000055a567583674 (anonymous namespace)::VirtRegRewriter::run(llvm::MachineFunction&) VirtRegMap.cpp:0:0
 #9 0x000055a56758413e (anonymous namespace)::VirtRegRewriterLegacy::runOnMachineFunction(llvm::MachineFunction&) VirtRegMap.cpp:0:0
#10 0x000055a567277c23 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (build/bin/llc+0x1458c23)
#11 0x000055a5677e8c55 llvm::FPPassManager::runOnFunction(llvm::Function&) (build/bin/llc+0x19c9c55)
#12 0x000055a5677f0b12 llvm::FPPassManager::runOnModule(llvm::Module&) (build/bin/llc+0x19d1b12)
#13 0x000055a5677e96b6 llvm::legacy::PassManagerImpl::run(llvm::Module&) (build/bin/llc+0x19ca6b6)
#14 0x000055a5663a56c9 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#15 0x000055a5663a2d2d main (build/bin/llc+0x583d2d)
#16 0x00007f56e3631ca8 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#17 0x00007f56e3631d65 call_init ./csu/../csu/libc-start.c:128:20
#18 0x00007f56e3631d65 __libc_start_main ./csu/../csu/libc-start.c:347:5
#19 0x000055a56639ec81 _start (build/bin/llc+0x57fc81)
Aborted (core dumped)

[llvmbot]

@llvm/issue-subscribers-backend-arm

Author: Hans Wennborg (zmodem)

We originally hit this building some PGO instrumented code for Android after a change to the SLP vectorizer; see https://github.com//pull/140279#issuecomment-3301887385 for the original reproducer.

However, it seems the SLP change may just have uncovered a pre-existing backend problem.

To reproduce:

$ cat reduced.ll
target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7-unknown-linux-android29"

define void @<!-- -->_ZN11VersionEdit10DecodeFromEv(i1 %call4, ptr %__profc__ZN11VersionEdit10DecodeFromEv) {
land.rhs.lr.ph:
  br i1 %call4, label %sw.bb, label %while.cond.while.end_crit_edge.split.loop.exit43

while.cond.while.end_crit_edge.split.loop.exit43: ; preds = %land.rhs.lr.ph
  %0 = extractelement &lt;4 x i64&gt; zeroinitializer, i64 0
  br label %while.cond.while.end_crit_edge

while.cond.while.end_crit_edge:                   ; preds = %sw.bb, %while.cond.while.end_crit_edge.split.loop.exit43
  %pgocount5374.ph = phi i64 [ %2, %sw.bb ], [ %0, %while.cond.while.end_crit_edge.split.loop.exit43 ]
  %1 = insertelement &lt;2 x i64&gt; splat (i64 1), i64 %pgocount5374.ph, i64 1
  store &lt;2 x i64&gt; %1, ptr %__profc__ZN11VersionEdit10DecodeFromEv, align 8
  ret void

sw.bb:                                            ; preds = %land.rhs.lr.ph
  %2 = extractelement &lt;4 x i64&gt; splat (i64 1), i64 0
  br label %while.cond.while.end_crit_edge
}

$ build/bin/llc reduced.ll -o /dev/null
llc: /work/llvm-project/llvm/lib/CodeGen/VirtRegMap.cpp:733: void (anonymous namespace)::VirtRegRewriter::rewrite(): Assertion `PhysReg.isValid() &amp;&amp; "Invalid SubReg for physical register"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
Stack dump:
0.      Program arguments: build/bin/llc reduced.ll -o /dev/null
1.      Running pass 'Function Pass Manager' on module 'reduced.ll'.
2.      Running pass 'Virtual Register Rewriter' on function '@<!-- -->_ZN11VersionEdit10DecodeFromEv'
 #<!-- -->0 0x000055a56814a5d8 llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (build/bin/llc+0x232b5d8)
 #<!-- -->1 0x000055a568147d05 llvm::sys::RunSignalHandlers() (build/bin/llc+0x2328d05)
 #<!-- -->2 0x000055a56814b3f1 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 #<!-- -->3 0x00007f56e3647df0 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdf0)
 #<!-- -->4 0x00007f56e369c95c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #<!-- -->5 0x00007f56e3647cc2 raise ./signal/../sysdeps/posix/raise.c:27:6
 #<!-- -->6 0x00007f56e36304ac abort ./stdlib/abort.c:81:3
 #<!-- -->7 0x00007f56e3630420 __assert_perror_fail ./assert/assert-perr.c:31:1
 #<!-- -->8 0x000055a567583674 (anonymous namespace)::VirtRegRewriter::run(llvm::MachineFunction&amp;) VirtRegMap.cpp:0:0
 #<!-- -->9 0x000055a56758413e (anonymous namespace)::VirtRegRewriterLegacy::runOnMachineFunction(llvm::MachineFunction&amp;) VirtRegMap.cpp:0:0
#<!-- -->10 0x000055a567277c23 llvm::MachineFunctionPass::runOnFunction(llvm::Function&amp;) (build/bin/llc+0x1458c23)
#<!-- -->11 0x000055a5677e8c55 llvm::FPPassManager::runOnFunction(llvm::Function&amp;) (build/bin/llc+0x19c9c55)
#<!-- -->12 0x000055a5677f0b12 llvm::FPPassManager::runOnModule(llvm::Module&amp;) (build/bin/llc+0x19d1b12)
#<!-- -->13 0x000055a5677e96b6 llvm::legacy::PassManagerImpl::run(llvm::Module&amp;) (build/bin/llc+0x19ca6b6)
#<!-- -->14 0x000055a5663a56c9 compileModule(char**, llvm::LLVMContext&amp;) llc.cpp:0:0
#<!-- -->15 0x000055a5663a2d2d main (build/bin/llc+0x583d2d)
#<!-- -->16 0x00007f56e3631ca8 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#<!-- -->17 0x00007f56e3631d65 call_init ./csu/../csu/libc-start.c:128:20
#<!-- -->18 0x00007f56e3631d65 __libc_start_main ./csu/../csu/libc-start.c:347:5
#<!-- -->19 0x000055a56639ec81 _start (build/bin/llc+0x57fc81)
Aborted (core dumped)

[zmodem]

@CaseySmalley is there someone at arm who could help look into this?

[MacDue]

I've tracked this issue down to 1bb4306 (PR #127052), reverting fixes this issue. It seems a REG_SEQUENCE fold now adds invalid sub-registers. @arsenm

[arsenm]

I do think there's some problem with ARM's subregister definitions (i.e., see the revert in 9350906). shouldRewriteCopySrc shouldn't require manual correctness fixups in it

[sdesmalen-arm]

I can't immediately see any issues with the subregister definitions. It seems it is only possible to access the sub-registers of the DPR_VFP2 class, which represents D0..D15, and overlap with S0..S31. D16..D31 don't have overlapping 32-bit sub-registers.
The code in ARMBaseRegisterInfo::shouldRewriteCopySrc tries to guard against this, but seems too specific to catch this case.
But it probably shouldn't end up in that function with DPR as the SrcRC when ssub_0 is not a valid sub-register for that class to begin with.

[arsenm]

But it probably shouldn't end up in that function with DPR as the SrcRC when ssub_0 is not a valid sub-register for that class to begin with.

No, the API is bad here and currently conflates legality and profitability. But as it stands today the implementation of shouldRewriteCopySrc should be validating the subregister + register class compatibility. Something is wrong if the generic implementation, which just goes through the various generated register class matching functions, reports an illegal subregister + class

[arsenm]

Should be fixed by #161338