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