Re: [PATCH] [MSP430] Fix gcc.dg/pr85180.c and gcc.dg/pr87985.c timeouts for msp430-elf -mlarge

[Segher Boessenkool <segher at kernel dot crashing dot org>]

On Wed, Dec 12, 2018 at 12:09:19PM +0000, Jozef Lawrynowicz wrote:
> Compilation of gcc.dg/pr85180.c and gcc.dg/pr87985.c times out after 5 minutes
> for msp430 with -mlarge.
> 
> nonzero_bits1 (from rtlanal.c), recurses many times for each reg
> because reg_nonzero_bits_for_combine (combine.c) never considers using 
> last_set_nonzero_bits for the given reg when the reg is PSImode (i.e. Pmode for
> msp430-elf -mlarge).
> 
> nonzero bits for a mode of class MODE_PARTIAL_INT are valid for a mode of class
> MODE_INT, and vice-versa.

The unused bits in a MODE_PARTIAL_INT value are undefined, so nonzero_bits
isn't valid for conversion in either direction.

And *which* bits are undefined isn't defined anywhere either, so we cannot
convert to/from smaller MODE_INT modes, either.

> The existing comment in reg_nonzero_bits_for_combine
> explaining why last_set_nonzero_bits is valid even when the precision of the
> last set mode is less than the current mode, also explains why
> MODE_PARTIAL_INT and MODE_INT can be used interchangeably here:
> 
> > record_value_for_reg invoked nonzero_bits on the register
> > with nonzero_bits_mode (because last_set_mode is necessarily integral
> > and HWI_COMPUTABLE_MODE_P in this case) so bits in nonzero_bits_mode
> > are all valid, hence in mode too since nonzero_bits_mode is defined
> > to the largest HWI_COMPUTABLE_MODE_P mode.

I don't see how that follows; not all bits in MODE_PARTIAL_INT modes
are necessarily valid.

Perhaps it is true that you can return whatever you want here, for the
undefined bits in a partial int var; but you'll need to justify that
then, it isn't obvious to me at least.

> +	      && (GET_MODE_CLASS (mode) == MODE_INT
> +		  || GET_MODE_CLASS (mode) == MODE_PARTIAL_INT)))

That's SCALAR_INT_MODE_P fwiw.

Thanks,


Segher