https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #21 from John David Anglin <danglin at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #20) > (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 :-) This bug was fixed by changing PA_HARD_REGNO_MODE_OK. On the 32-bit target we no longer allow TI and OI mode in the hard registers. I only allowed complex 16 byte modes in the general registers. It's possible this is problematic but there isn't much testing. I removed 32 byte modes from the 64-bit targets.
