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.

Reply via email to