Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> As I explained to Eric, I would have been pleased to apply that
> patch.  However it turned out that it introduces (1) a performance
> regression; (2) possibly a wrong code generation -- David gave some
> references.

Note that, as I said to David, I'm very skeptical about (2) for the patch 
_alone_ because it simply pessimizes (however rightfully, they are just 
plain wrong in the general case) the values returned by two predicate 
functions:


/* Given an expression, X, compute which bits in X can be non-zero.
   We don't care about bits outside of those defined in MODE.

   For most X this is simply GET_MODE_MASK (GET_MODE (MODE)), but if X is
   a shift, AND, or zero_extract, we can do better.  */

static unsigned HOST_WIDE_INT
nonzero_bits (x, mode)

/* Return the number of bits at the high-order end of X that are known to
   be equal to the sign bit.  X will be used in mode MODE; if MODE is
   VOIDmode, X will be used in its own mode.  The returned value  will always
   be between 1 and the number of bits in MODE.  */

static unsigned int
num_sign_bit_copies (x, mode)


> Therefore, to fix the new regressions we would have to grab
> other patches not known to be safe.  The initial patch was beginning
> to have too much ramifications.

I can't disagree here.

> I would suggest that, right after 3.2.2 release, interested parties
> investigate the issue and submit a complete patch which we would
> have sufficient time to test.

I'm not very optimistic about this happening. I guess most of the developer
resources will be focused on the 3.3 branch instead.

-- 
Eric Botcazou