[Bug tree-optimization/98856] [11 Regression] botan AES-128/XTS is slower by ~17% since r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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.