This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Followup for reg_equiv_invariant patch: Fix PR39871


On 07/31/10 08:46, Bernd Schmidt wrote:
On 07/24/2010 03:09 PM, IainS wrote:
On 17 Jun 2010, at 22:53, Bernd Schmidt wrote:

This is what I committed after retesting on ARM (with -O2 -fpic included
in TORTURE_OPTIONS).
this caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45054
Hmm, there seem to be two latent problems that suddenly show up in one
testcase...

In replace_pseudos_in, we have a series of if statements, which tries to
pick the correct new home from the various possible alternatives.  This
seems to need a check for reg_equiv_invariant.
Strange. Why wasn't this necessary in the past?

The other is a crash because when compiling a function with 120 or so
registers, spilled_pseudos has bit 165 set from the previous function -
it's not cleared at the top of reload, and if I had to hazard a guess,
it wasn't cleared in ira_reassign_pseudos due to ALLOCNO_DONT_REASSIGN_P
(conflict_a) or somesuch while compiling the previous function.
What I see is we've disabled wiping spilled_pseudos in the main reload loop because its state needs to be carried across iterations, but nothing was added to wipe spilled_pseudos at either the very beginning or very end of reload, thus the pollution of the bitmap. I don't see how ALLOCNO_DONT_REASSIGN_P plays into this.

One could certainly discuss why we need to accumulate the set of spills in spilled_pseudos from one iterations of the main reload loop to the next. It seems wrong, but there's probably some subtle reason for this change in behavior that I'm missing. The comment certainly isn't clear enough on this issue.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]