Re: A few simple DImode improvements

[Ian Lance Taylor <iant at google dot com>]

Eric Botcazou <ebotcazou@adacore.com> writes:

>> The changes in the lower-subreg pass are motivated by nonsensical
>> transformations like the following:
>>
>> -(insn 205 204 26 4  (set (reg:DI 68)
>> -        (reg:DI 178)) 49 (REG_DEAD (reg:DI 178)
>> +(insn 261 204 262 4  (clobber (reg:DI 193))
>> +
>> +(insn 262 261 263 4  (set (subreg:SI (reg:DI 193) 0) (reg:SI 191))
>> +
>> +(insn 263 262 264 4  (set (subreg:SI (reg:DI 193) 4) (reg:SI 192))
>> +
>> +(insn 264 263 26 4  (set (reg:DI 68) (reg:DI 193))
>>
>> In resolve_simple_move, we generate a new DImode temporary pseudo rather
>> than storing into the DImode pseudo which is the actual destination.
>> This, I think, is due to confusion about the use of can_decompose_p; it
>> makes sense to use it in this context only for hard regs.  For pseudos,
>> it tests the non_decomposable_context bitmap, which is irrelevant here.
>
> can_decompose_p is only used in this context though.  But I agree that this 
> looks superfluous.
>
> Ian, do you have any insight here?

It's superfluous for a simple example like this one, but it's not
clearly superfluous in all cases.  If register 68 here should wind up
being allocated to a floating point register which can't be SUBREG'ed,
then my concern is that taking a SUBREG is going to make it harder to
allocate the register correctly.  In other words, the bitmap is not
irrelevant; it's a proxy for non-SImode register classes.  I don't know
whether this a concern with IRA; can IRA allocate a DImode pseudo to a
floating point register if there are SImode SUBREGs of it?  The old
register allocator wouldn't, and you could wind up with a bunch of
reloads.

(I actually had patches for the old register allocator which tracked
subregs independently to improve allocation for cases like this.  I
delayed them to wait for the dataflow work, and then they became
irrelevant with IRA.)

Ian