Re: [PATCH] Fix compile/memory hog in the combiner (PR rtl-optimization/69592)

[Bernd Schmidt <bschmidt at redhat dot com>]

On 02/01/2016 09:34 PM, Jakub Jelinek wrote:
> On the following testcase we completely uselessly consume about 5.5GB
> of RAM and lots of compile time.  The problem is the code to avoid
> exponential behavior of nonzero_bits/num_sign_bit_copies on binary
> arithmetics rtxes, which causes us to recurse even when handling
> of those rtxes is going to ignore those arguments.
> So, this patch limits those only to the cases where we are going
> to recurse on both arguments, for rtxes where we don't look at arguments
> at all or where we only recurse on a single arguments it doesn't make
> sense.  On the testcase, one of the rtxes where the new predicates
> return false but ARITHMETIC_P is true, is COMPARE, in particular
> (compare:CCC (plus (x) (y)) (x)), where it is known even without
> looking at the operands that only one bit is possibly non-zero and
> number of sign bit copies is always 1.  But without the patch we
> needlessly recurse on x, which is set by another similar operation etc.

Hmm, so the code we have to eliminate performance problems is itself 
causing them?
I don't see any code handling COMPARE in nonzero_bits1, only the various 
EQ/NE/etc. codes.

> +static inline bool
> +nonzero_bits_binary_arith_p (const_rtx x)
> +{
> +  if (!ARITHMETIC_P (x))
> +    return false;
> +  switch (GET_CODE (x))
> +    {
> +    case AND:
> +    case XOR:
> +    case IOR:
> +    case UMIN:
> +    case UMAX:
> +    case SMIN:
> +    case SMAX:
> +    case PLUS:
> +    case MINUS:
> +    case MULT:
> +    case DIV:
> +    case UDIV:
> +    case MOD:
> +    case UMOD:
> +      return true;
> +    default:
> +      return false;
> +    }

I think I have a slight preference for listing the cases where we know 
we can avoid the exponential behaviour workaround - i.e. just test for 
compares and return false for them. Otherwise someone might add another 
of the arithmetic codes to nonzero_bits without noticing they have to 
adjust this function as well.


Bernd