This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why does lower-subreg mark copied pseudos as "decomposable"?
Andrew Stubbs <ams@codesourcery.com> writes:
> On 18/04/12 11:55, Richard Sandiford wrote:
>> The problem is that not all register moves are always going to be
>> eliminated, even when no mode changes are involved. It might make
>> sense to restrict that code you quoted:
>>
>> case SIMPLE_PSEUDO_REG_MOVE:
>> if (MODES_TIEABLE_P (GET_MODE (x), word_mode))
>> bitmap_set_bit (decomposable_context, regno);
>> break;
>>
>> to the second pass though.
>
> Yes, I thought of that, but I dismissed it because the second pass is
> really very late. It would be just in time to take advantage of the
> relaxed register allocation, but would miss out on all the various
> optimizations that forward-propagation, combining, and such can offer.
>
> This is why I've tried to find a way to do something about it in the
> first pass. I thought it makes sense to do something for none-no-op
> moves (when is there such a thing, btw, without it being and extend,
> truncate, or subreg?),
AFAIK there isn't, which is why I'm a bit unsure what you're suggesting.
Different modes like DI and DF can both be stored in NEON registers,
so if you have a situation where one is punned into the other,
I think that's an even stronger reason to want to keep them together.
> but the no-op moves are trickier.
>
> Perhaps a combination of the two ideas? Decompose mode-changing moves in
> the first pass, and all moves in the second?
>
> BTW, the lower-subreg pass has a forward propagation concept of its own.
> If I read it right, even with the above changes, it will still decompose
> the move if the register it copies from has been decomposed, and the
> register it copies to is not marked 'non-decomposable'.
Right.
> Hmm, I'm going to try to come up with some testcases that demonstrate
> the different cases and see if that helps me think about it. Do you
> happen to have any to hand?
'Fraid not, sorry.
>> OK. If/when that patches goes in, the ARM backend is going to have
>> to pick an rtx cost for DImode SETs. It sounds like the cost will need
>> to be twice an SImode move regardless of whether or not NEON is enabled.
>
> That sounds reasonable. Of course, how much a register move costs is a
> tricky subject for NEON anyway. :(
Yeah.
Richard