Richard Sandiford <[EMAIL PROTECTED]> writes: > I think one reason is that allowing zero_extracts of multi-word modes is > (like this subreg thing) a little hard to pin down. What happens when > WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN on a 32-bit target, and you have: > > (zero_extract (reg:DI ....) (const_int 16) (const_int 24)) > > (which should be BITS_BIG_ENDIAN-neutral). 0x76543210 would be laid out > in memory as "0x45670123", so is this extract equivalent to "0x70" or > "0x43"? You could probably make a case for both, and I doubt the > target-independent code handles this consistently at the moment.
Sorry, those 0x numbers were base 256. ;) Richard
