This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Don't try to reload match_operator
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Richard Earnshaw <rearnsha at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at buzzard dot freeserve dot co dot uk>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "bernds at codesourcery dot com" <bernds at codesourcery dot com>
- Date: Mon, 10 Oct 2011 18:54:40 -0400 (EDT)
- Subject: Re: [patch] Don't try to reload match_operator
- References: <201109191553.p8JFrVQd001204@d06av02.portsmouth.uk.ibm.com>
On Mon, 19 Sep 2011, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
> > On 19/09/11 15:14, Ulrich Weigand wrote:
> > > So it seems to me that for match_operator operands, the
> > > goal_alternative_win flag should always be true ...
> > >
> > > Can you find out why this isn't true in your case?
> >
> > Hmm, I think it must be because of this:
> >
> > /* If the operand is a SUBREG, extract
> > the REG or MEM (or maybe even a constant) within.
> > (Constants can occur as a result of reg_equiv_constant.) */
> >
> > while (GET_CODE (operand) == SUBREG)
> > {
> > ...
> > force_reload = 1;
> > }
>
> Ah, right. Note that immediately before this "while" we have:
>
> /* If the predicate accepts a unary operator, it means that
> we need to reload the operand, but do not do this for
> match_operator and friends. */
> if (UNARY_P (operand) && *p != 0)
> operand = XEXP (operand, 0);
>
> The "... but do not do this for match_operator and friends" part is
> implemented by the "*p != 0" check here. It seems we need the same
> check for the SUBREG test.
FWIW, if anyone wonders, the comment refers to a special-case
misfeature that should be removed (if a predicate matches an
unop, the constraint will only see the inner expression).
Reload doesn't do what's intended - at least not what the SH
port intended with its use at the time, and there be bugs there
too. While we had agreement that the misfeature should be
removed, the removal never happened. This was 6 years ago, JFTR
<http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00940.html> and
<http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01376.html>
(what a yucky macro, consider the latter patch withdrawn. :)
brgds, H-P