This is the mail archive of the
mailing list for the GCC project.
Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX
- From: Jeff Law <law at redhat dot com>
- To: sje at cup dot hp dot com
- Cc: Peter Bergner <bergner at vnet dot ibm dot com>, luisgpm at linux dot vnet dot ibm dot com, Andrew Pinski <pinskia at gmail dot com>, Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org, paolo dot carlini at oracle dot com
- Date: Thu, 06 Nov 2008 10:34:44 -0700
- Subject: Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX
- References: <200809161651.m8GGpEM19079@lucas.cup.hp.com> <firstname.lastname@example.org> <48D0248E.email@example.com> <firstname.lastname@example.org> <48D2B834.email@example.com> <firstname.lastname@example.org> <48D953DC.email@example.com> <firstname.lastname@example.org> <1223062006.612.13.camel@gargoyle> <48E6BB7D.email@example.com> <firstname.lastname@example.org> <1224182072.8846.94.camel@gargoyle> <48F78BD3.email@example.com> <1225370489.23514.9.camel@gargoyle> <firstname.lastname@example.org> <1225390882.6757.35.camel@otta> <4909FF11.email@example.com> <firstname.lastname@example.org>
Steve Ellcey wrote:
On Thu, 2008-10-30 at 12:38 -0600, Jeff Law wrote:I figured it was simply a matter of some pass changing the code and
hence hiding the problem.
We shouldn't be hacking up backends to deal with this problem, it's
entirely the wrong approach.
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.
Given a hard register #, you can't map back to its usage without
scanning the RTL as hard registers are not shared, particularly after
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).
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.