https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #20 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to John David Anglin from comment #19) > (In reply to Segher Boessenkool from comment #17) > > (In reply to John David Anglin from comment #15) > > > While bootstrap is okay, there are some new test fails: > > > > > > AIL: gcc.c-torture/compile/pr92618.c -O1 (internal compiler error: > > > maximum number of generated reload insns per insn achieved (90)) > > > > (And all failures are like this. Are they all caused buy the same thing, > > too?) > > > > > I think the maximum number of generated reloads per insn may need > > > increasing > > > to fix above. > > > > No, no finite number will fix it. The problem is that LRA sees some > > problematic insn for which it needs some reloading, but one of the insns > > it comes up with is the same exact shape as the original problematic insn, > > so we are in an infinite loop here. > > There were some problems like this that I managed to fix by changing > pa_secondary_reload. Almost all target problems that manifest during LRA manifest like this. If you can figure out a way to make such things easier to debug for the next fellow sufferer, that would be super useful, people will love you! > > The maximum used to be 30 btw, but apparently there were cases where we > > actually needed that many reloads. But we never need anything close to 90, > > on any target. So far, anyway. > The above test generates a large number of reload insns with SUBREGs. > Doesn't appear to be an infinite loop. Test only fails on 32-bit hppa. > That's why I thought it was caused by triggering limit. Oh, it is *possible* increasing the limit will help, but 90 already was chosen as infeasibly high (and 30 before that as well, so certainly it is possible we need another increment, but not very likely). > > > FAIL: 20_util/variant/run.cc -std=gnu++17 (test for excess errors) > > > UNRESOLVED: 20_util/variant/run.cc -std=gnu++17 compilation failed to > > > produce executable > > > FAIL: > > > 23_containers/vector/requirements/exception/generation_prohibited.cc > > > -std=gnu++17 (test for excess errors) > > > UNRESOLVED: > > > 23_containers/vector/requirements/exception/generation_prohibited.cc > > > -std=gnu++17 compilation failed to produce executable > > > FAIL: std/ranges/cartesian_product/1.cc -std=gnu++23 (test for excess > > > errors) > > > UNRESOLVED: std/ranges/cartesian_product/1.cc -std=gnu++23 compilation > > > failed to produce executable > > > FAIL: std/ranges/cartesian_product/1.cc -std=gnu++26 (test for excess > > > errors) > > > UNRESOLVED: std/ranges/cartesian_product/1.cc -std=gnu++26 compilation > > > failed to produce executable > > > > > > These appear caused by incorrect selection of class R1_REGS. Not sure > > > why or what to do about it. > > > > Chosen by LRA? Chosen for new insns generated by LRA? > > I think so based on looking at the dump for the reload pass but I'm > not sure. > > I believe the insn was not generated by LRA. LRA was unable to find > hard registers for a (set (MEM (REG1)) (REG2)) insn in the above test > failures. This is a very common pattern. Need to look at what happened > to the sets for REG1 and REG2. > > Register r1 is somewhat special in that it is the only register that > can be used as the destination of addil instructions. Maybe some constraint modifier thing is needed? I don't know pa all that well, sorry :-/ > I will open bug reports when I have more information. Thanks! And good luck. Debugging LRA is hard because of LRA itself, as well as simply hard from what it does in the first place, *and* the art of debugging it a whole separate world anyway! So again, anything that can make it easier for the next poor sod who will find him/herself in the same position, is more than welcome :-)
