Andrew Stubbs <a...@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
