Rework subreg_get_info

Eric Botcazou <ebotcazou@adacore.com> writes:
>> Well, I think it's probably grammatical, but how about:
>> 
>>   If the register representation of a non-scalar mode has holes in it,
>>   we expect the scalar units to be concatenated together, with the holes
>>   distributed evenly among the scalar units.  Each scalar unit must occupy
>>   at least one register.
>
> Fine with me, thanks.
>
>> This actually was one of the more important changes :-)  In combination
>> with later patches, the idea is to move away from UNITS_PER_WORD tests
>> when endianness is regular (all big or all little) and only do them
>> when the distinction between bytes and words makes a real difference.
>> 
>> The specific motivating examples were SVE predicate registers, which
>> occupy VL*2 bytes for some runtime VL.  They are smaller than a word
>> when VL<4, word-sized when VL==4, and bigger than a word when VL>4.
>> We therefore can't calculate:
>> 
>>   GET_MODE_SIZE (ymode) > UNITS_PER_WORD
>> 
>> at compile time.  This is one of the patches that avoids forcing the
>> issue unless the answer really matters.
>
> So you plan to modify it again to remove the ysize > UNITS_PER_WORD
> test?  Or you don't really care about the REG_WORDS_BIG_ENDIAN !=
> WORDS_BIG_ENDIAN case?

Yeah, a later patch changed the form of the comparison so that it
forced the ordering wrt UNITS_PER_WORD to be known at compile time
(if the comparison was reached).  The idea is to do that kind of thing
only as a last resort, when there's a known reason for it to be safe.

> I understand that this formulation is intended to hide various combinations of 
> WORDS_BIG_ENDIAN and BYTES_BIG_ENDIAN, but it's a net loss for most targets 
> where the old code boils down to an unconditional assignment to info->offset.
> Would it be doable to use the same handling as in subreg_size_lowpart_offset?

Actually, thinking more about it: the assumption we're making in the
WORDS_BIG_ENDIAN != REG_WORDS_BIG_ENDIAN condition discussed below is
really:

  /* We assume that the ordering of registers within a multi-register
     value has a consistent endianness: if bytes and register words
     have different endianness, the hard registers that make up a
     multi-register value must be at least word-sized.  */

(quoted from the revised patch below).  And with that assumption this
check is simply REG_WORDS_BIG_ENDIAN vs. !REG_WORDS_BIG_ENDIAN.

(I've checked ports for mixed byte/word endianness (think that's
just pdp11) and word/reg-word endianness (think that's just c6x),
and the assumption does seem to hold.  I'd be very surprised if we
coped correctly with more exotic combinations, including for the
reasons quoted below.)

>> For WORDS_BIG_ENDIAN != REG_WORDS_BIG_ENDIAN targets?  In practice
>> the old code didn't handle the case in which a single word spans more
>> than one register: if xmode was bigger than a word, ymode was smaller
>> than a word, and the number of registers in a ymode was smaller than
>> the number of registers in a word, we would need to take "normal"
>> endianness into account to resolve the subword register offset while
>> using REG_WORDS_BIG_ENDIAN for the word component.  Instead the old
>> code reversed the endianness relative the size of ymode, regardless of
>> whether ymode was bigger than a word or smaller than a word.  In other
>> words, the assumption seems to have been that REG_WORDS_BIG_ENDIAN is
>> effectively "endianness across multiple registers" and there is no need
>> to subdivide register offsets into words and subwords.
>> 
>> In practice that was OK, since AFAICT no target with WORDS_BIG_ENDIAN !=
>> REG_WORDS_BIG_ENDIAN had subword-sized registers.  This in turn means
>> that "block endianness" is always word endianness for these targets.
>
> Since you tested on c6x-elf, that's OK, but I think that a comment
> before the if (WORDS_BIG_ENDIAN != REG_WORDS_BIG_ENDIAN) test would be
> in order, stating the implicit assumption made at this point.

OK, how does this look?

Thanks,
Richard

gcc/
2016-11-15  Richard Sandiford  <richard.sandiford@arm.com>
	    Alan Hayward  <alan.hayward@arm.com>
	    David Sherwood  <david.sherwood@arm.com>

	* rtlanal.c (subreg_get_info): Use more local variables.
	Remark that for HARD_REGNO_NREGS_HAS_PADDING, each scalar unit
	occupies at least one register.  Assume that full hard registers
	have consistent endianness.  Share previously-duplicated if block.
	Rework the main handling so that it operates on independently-
	addressable YMODE-sized blocks.  Use subreg_size_lowpart_offset
	to check lowpart offsets, without trying to find an equivalent
	integer mode first.  Handle WORDS_BIG_ENDIAN != REG_WORDS_BIG_ENDIAN
	as a final register-endianness correction.

Rework subreg_get_info

Commit Message

Comments

Patch