Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area
On 07/05/2011 01:54 AM, Alan Modra wrote: Before that, fwprop never tries to work on hard registers. I question this claim. It seems to me that fwprop did look at paradoxical subregs of hard regs before my change. That wasn't part of the design anyway. The main purpose of fwprop's paradoxical subreg propagation is to get rid of back-to-back SI-to-QI-to-SI conversions, and working with pseudos is enough. The patch is okay as far as I'm concerned, but I'm not a maintainer of fwprop. Perhaps it could be conditionalized on SMALL_REGISTER_CLASSES (that's the source of the bug, I think: the single-register class D conflicts with an argument register) but I don't think it's worth it. Paolo
Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area
Paolo Bonzini bonz...@gnu.org writes: On 07/05/2011 01:54 AM, Alan Modra wrote: Before that, fwprop never tries to work on hard registers. I question this claim. It seems to me that fwprop did look at paradoxical subregs of hard regs before my change. That wasn't part of the design anyway. The main purpose of fwprop's paradoxical subreg propagation is to get rid of back-to-back SI-to-QI-to-SI conversions, and working with pseudos is enough. OK, in that case H.J., please go ahead. The patch is okay as far as I'm concerned, but I'm not a maintainer of fwprop. You probably should be :-) Richard
Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area
On 07/05/2011 10:51 AM, Richard Sandiford wrote: The patch is okay as far as I'm concerned, but I'm not a maintainer of fwprop. You probably should be:-) I'd have no problem with that! Paolo
Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area
H.J. Lu hongjiu...@intel.com writes: RTL-based forward propagation pass shouldn't propagate hard register. That's seems a bit draconian. Many fixed hard registers ought to be OK. E.g. there doesn't seem to be anything wrong with propagating uses of the stack or frame pointers, subject to the usual availability checks. To play devil's advocate, an alternative might be to (a) make local_ref_killed_between_p return true for non-fixed hard registers when a call or asm comes between the two instructions (b) make use_killed_between return true for non-fixed hard registers when the instructions are in different basic blocks Thoughts? Richard
Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area
On Mon, Jul 4, 2011 at 12:57 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
H.J. Lu hongjiu...@intel.com writes:
RTL-based forward propagation pass shouldn't propagate hard register.
That's seems a bit draconian. Many fixed hard registers ought to be OK.
E.g. there doesn't seem to be anything wrong with propagating uses of
the stack or frame pointers, subject to the usual availability checks.
To play devil's advocate, an alternative might be to
(a) make local_ref_killed_between_p return true for non-fixed hard
registers when a call or asm comes between the two instructions
(b) make use_killed_between return true for non-fixed hard registers
when the instructions are in different basic blocks
Thoughts?
There are a few problems with this suggestions:
1. The comments says:
/* If USE is a subreg, see if it can be replaced by a pseudo. */
static bool
forward_propagate_subreg (df_ref use, rtx def_insn, rtx def_set)
{
It indicates this function is intended to work on pseudo registers.
2. propagate_rtx avoids hard registers:
static rtx
propagate_rtx (rtx x, enum machine_mode mode, rtx old_rtx, rtx new_rtx,
bool speed)
{
rtx tem;
bool collapsed;
int flags;
if (REG_P (new_rtx) REGNO (new_rtx) FIRST_PSEUDO_REGISTER)
return NULL_RTX;
It seems that fwprop is intended to deal with pseudo registers. If we
want to extend it to hard registers, that should be a separate project.
Thanks.
--
H.J.
Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area
On Mon, Jul 4, 2011 at 1:52 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Jul 4, 2011 at 12:57 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
H.J. Lu hongjiu...@intel.com writes:
RTL-based forward propagation pass shouldn't propagate hard register.
That's seems a bit draconian. Many fixed hard registers ought to be OK.
E.g. there doesn't seem to be anything wrong with propagating uses of
the stack or frame pointers, subject to the usual availability checks.
To play devil's advocate, an alternative might be to
(a) make local_ref_killed_between_p return true for non-fixed hard
registers when a call or asm comes between the two instructions
(b) make use_killed_between return true for non-fixed hard registers
when the instructions are in different basic blocks
Thoughts?
There are a few problems with this suggestions:
1. The comments says:
/* If USE is a subreg, see if it can be replaced by a pseudo. */
static bool
forward_propagate_subreg (df_ref use, rtx def_insn, rtx def_set)
{
It indicates this function is intended to work on pseudo registers.
2. propagate_rtx avoids hard registers:
static rtx
propagate_rtx (rtx x, enum machine_mode mode, rtx old_rtx, rtx new_rtx,
bool speed)
{
rtx tem;
bool collapsed;
int flags;
if (REG_P (new_rtx) REGNO (new_rtx) FIRST_PSEUDO_REGISTER)
return NULL_RTX;
It seems that fwprop is intended to deal with pseudo registers. If we
want to extend it to hard registers, that should be a separate project.
Thanks.
forward_propagate_subreg issue was introduced by
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01203.html
Before that, fwprop never tries to work on hard registers. Alan,
is your change to process hard registers intentional?
Thanks.
--
H.J.
Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area
On Mon, Jul 04, 2011 at 01:57:34PM -0700, H.J. Lu wrote: forward_propagate_subreg issue was introduced by http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01203.html Before that, fwprop never tries to work on hard registers. I question this claim. It seems to me that fwprop did look at paradoxical subregs of hard regs before my change. Alan, is your change to process hard registers intentional? I didn't set out to do anything special with hard regs one way or the other, just extended what was already done for paradoxical subregs to sign and zero extended subregs. -- Alan Modra Australia Development Lab, IBM
Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area
On Mon, Jul 4, 2011 at 4:54 PM, Alan Modra amo...@gmail.com wrote: On Mon, Jul 04, 2011 at 01:57:34PM -0700, H.J. Lu wrote: forward_propagate_subreg issue was introduced by http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01203.html Before that, fwprop never tries to work on hard registers. I question this claim. It seems to me that fwprop did look at paradoxical subregs of hard regs before my change. I should have said fwprop never tries to work on zero/sign-extended hard registers. Alan, is your change to process hard registers intentional? I didn't set out to do anything special with hard regs one way or the other, just extended what was already done for paradoxical subregs to sign and zero extended subregs. Does your change depend on processing zero/sign-extended hard registers? -- H.J.
Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area
On Mon, Jul 04, 2011 at 05:09:28PM -0700, H.J. Lu wrote: On Mon, Jul 4, 2011 at 4:54 PM, Alan Modra amo...@gmail.com wrote: I didn't set out to do anything special with hard regs one way or the other, just extended what was already done for paradoxical subregs to sign and zero extended subregs. Does your change depend on processing zero/sign-extended hard registers? At the time I wrote the patch I was more interested in pseudos. I expect that powerpc64 won't be greatly affected if hard regs were excluded from this fwprop optimization, but you need to discuss your patch with maintainers of this code. My opinion as a one-time contributor to fwprop doesn't count for much. -- Alan Modra Australia Development Lab, IBM
