[PATCH][combine][1/2] Try to simplify before substituting

[Kyrill Tkachov]

On 16/07/15 19:13, Segher Boessenkool wrote:
> On Thu, Jul 16, 2015 at 04:25:14PM +0100, Kyrill Tkachov wrote:
>> Hi all,
>>
>> This is an attempt to solve the problem in the thread starting at
>> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01010.html
>> in a generic way after some pointers from Segher and Andrew.
>>
>> The problem I got was that combine_simplify_rtx was trying to
>> do some special handling of unary operations applied to if_then_else
>> but ended up exiting early due to:
>>
>>        enum rtx_code cond_code = simplify_comparison (NE, &cond, &cop1);
>>
>>        if (cond_code == NE && COMPARISON_P (cond))
>>          return x;
>>
>> I tried removing that bug that led to regressions in SPEC2006.
>> The solution that worked for me led to two patches.
>>
>> In this first patch we add a simplification step to the rtx before trying
>> any substitutions.
>> diff --git a/gcc/combine.c b/gcc/combine.c
>> index 574f874..40d2231 100644
>> --- a/gcc/combine.c
>> +++ b/gcc/combine.c
>> @@ -5510,6 +5510,17 @@ combine_simplify_rtx (rtx x, machine_mode op0_mode, int in_dest,
>>       {
>>         rtx cond, true_rtx, false_rtx;
>>   
>> +      /* If some simplification is possible from the start, try it now.  */
>> +      temp = simplify_rtx (x);
>> +
>> +      if (temp)
>> +	{
>> +	  x = temp;
>> +	  code = GET_CODE (x);
>> +	  mode = GET_MODE (x);
>> +	  op0_mode = VOIDmode;
>> +	}
>> +
>>         cond = if_then_else_cond (x, &true_rtx, &false_rtx);
>>         if (cond != 0
>>   	  /* If everything is a comparison, what we have is highly unlikely
> If you always want to simplify first, does it work to move this whole big
> block behind the simplify just following it?  Or do you want to simplify
> after the transform as well?

You mean move this hunk outside the "if (BINARY_P (x)...)" block it's in?
I think it would work, but I'm not sure if it would affect other cases.
I was also conscious that simplify_rtx might not be a cheap function to call
so frequently (or is it? I didn't profile it), so I tried to avoid calling
it unless I need for the transformation in question here.

Kyrill

>
>
> Segher
>