[patch] Don't try to reload match_operator

Richard Earnshaw rearnsha@arm.com
Mon Sep 19 17:10:00 GMT 2011


On 19/09/11 15:14, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
> 
>> This patch fixes a couple of cases where reload incorrectly thinks it
>> should be messing around with the result of a match_operator operand.
>> Given that it's never even tried to validate the contents of such an
>> operand the changes it tries to make are bogus.
> 
> I'm wondering why this change is necessary; existing code seems to
> attempt to handle match_operator operands by detecting an empty
> constraint string:
> 
>       if (*constraints[i] == 0)
>         /* Ignore things like match_operator operands.  */
>         ;
> [...]
>           /* An empty constraint or empty alternative
>              allows anything which matched the pattern.  */
>           if (*p == 0 || *p == ',')
>             win = 1, badop = 0;
> 
> 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?
> 
> Bye,
> Ulrich
> 

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;
	    }

then later

	  if (win && ! force_reload)
	    this_alternative_win[i] = 1;

which is matching because my match_operator is specifically trying to
match a subreg of a complex expression (the high-word of a
multiply-accumulate operation -- this has to be done with match_operator
because the subreg_reg changes between big and little-endian).  This
then causes badop to be set later on which causes the alternative to
fail to match.  So maybe it's the SUBREG test above that needs fixing to
not apply when we have match_operator.

Thoughts?

R.



More information about the Gcc-patches mailing list