Interesting investigation. But it sounds like the discssion revealed that this may be "just" a regression.
Reminds me of a Zig stream I watched recently where Andy was updating the compiler backend to use an LLVM 12 release candidate. He ended up filling a couple bug reports with LLVM, using Zig compiler issues to generate reduced case LLVM IR examples that compiled differently with LLVM 11. He mentioned that he had to try this upgrade with the release candidate because right now they're LLVM regressions, but once 12 ships they become Zig regressions!
And Zig developers also do a very good job at reporting and fixing them. Which is why contributing to Zig also means contributing to LLVM.
LLVM's [1] includes (some of?) gcc's, the reverse may also be true.
LLVM also has extensive unit tests that can exercise codegen and backend functionality.
It's what cranelift does.
You could do it with a reference compiler (this has in fact been done before) but finding suboptimal codegen like this case would still be kinda tricky.
Generally, codegen issues are exposed by benchmarks or someone who is curious enough to examine and analyze the code generated from multiple compilers or multiple releases. The latter is much rarer. But as these happen, the bar keeps getting raised and we do grow the test suite.
If your compiler generates IR that's just awful enough that it's a coin toss whether the backend can optimize it, whereas it can optimize the "naive" IR you'd write by hand, it's a compiler problem, not a backend problem.