https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #25 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 5 Mar 2021, ubizjak at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856 > > --- Comment #24 from Uroš Bizjak <ubizjak at gmail dot com> --- > (In reply to Richard Biener from comment #22) > > I guess the idea of this insn setup was exactly to get IRA/LRA choose > > the optimal instruction sequence - otherwise exposing the reload so > > late is probably suboptimal. > > THere is one more tool in the toolbox. A peephole2 pattern can be > conditionalized on availabe XMM register. So, if XMM reg is available, the > GPR->XMM move can be emitted in front of the insn. So, if there is XMM > register > pressure, pinsrd will be used, but if an XMM register is availabe, it will be > reused to emit punpcklqdq. > > The peephole2 pattern can also be conditionalized for targets where GPR->XMM > moves are fast. Note the trick is esp. important when GPR->XMM moves are _slow_. But only in the case we originally combine two GPR operands. Doing two GPR->XMM moves and then one puncklqdq hides half of the latency of the slow moves since they have no data dependence on each other. So for the peephole we should try to match this - a reloaded operand and a GPR operand. When the %xmm operand results from a SSE computation there's no point in splitting out a GPR->XMM move. So in the end a peephole2 sounds like it could better match the condition the transform is profitable on.
