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: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX


Steve Ellcey wrote:
On Thu, 2008-10-30 at 12:38 -0600, Jeff Law wrote:

We shouldn't be hacking up backends to deal with this problem, it's entirely the wrong approach.


jeff

So I looked at why I wasn't seeing this in ToT with -O3 and found that
it was due to the selective scheduler checkin. However, If I use -O2
-funroll-all-loops I can still reproduce this at ToT after removing my
patch or after changing it to not affect hard registers.
I figured it was simply a matter of some pass changing the code and hence hiding the problem.

I am thinking that the right approach is to change regrename somewhere
so that a hard register with REG_POINTER set to true and a hard register
with REG_POINTER set to false are not allowed in a rename (at least not
on IA64 HP-UX in ILP32 mode).  HARD_REGNO_RENAME_OK seems like the
natural place to do this but it takes register numbers as arguments and
I don't know how to find the REG_POINTER value for a hard register from
just the register number (as opposed to having an actual register RTL).

Given a hard register #, you can't map back to its usage without scanning the RTL as hard registers are not shared, particularly after register allocation.

I really think we need to go back and look at handling this better in alias.c -- that's really the only thing that's being complained about. If we can't find a way to fix alias.c, then and only then should we look at workarounds such as avoiding renaming on values with REG_POINTER set and similar hacks.

Jeff


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