This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]