From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0D4E43938C1F; Mon, 1 Mar 2021 14:53:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0D4E43938C1F From: "rguenth at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug string/27457] vzeroupper use in AVX2 multiarch string functions cause HTM aborts Date: Mon, 01 Mar 2021 14:53:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: string X-Bugzilla-Version: 2.31 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: hjl.tools at gmail dot com X-Bugzilla-Target-Milestone: 2.34 X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 14:53:24 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27457 --- Comment #21 from Richard Biener --- (In reply to H.J. Lu from comment #19) > (In reply to Richard Biener from comment #17) > > (In reply to H.J. Lu from comment #11) > > > (In reply to Florian Weimer from comment #9) > > > > (In reply to rguenther from comment #7) > > > > > On Mon, 1 Mar 2021, fweimer at redhat dot com wrote: > > > > > > The sources do not seem to show the selection logic. > > > > > > __memset_avx2_unaligned_rtm seems to simply have dropped the VZ= EROUPPER > > > > > > instruction, which can't be good for general application perfor= mance. > > > > >=20 > > > > > The intent was to use %ymm16+ only which does not cause any trans= ition > > > > > penalty even w/o vzeroupper. > > > >=20 > > > > I still saw %ymm0 usage in the disassembly, if I recall correctly. = And for > > > > AVX2, there isn't much choice. I didn't try to reverse-engineer the > > > > corresponding IFUNC selector. > > >=20 > > > At function exit, there is > > >=20 > > > f3: 0f 01 d6 xtest=20=20 > > > f6: 74 04 je fc <__memset_avx2_unaligned_erms_r= tm+0x5c> > > > f8: c5 fc 77 vzeroall=20 > > > fb: c3 ret=20=20=20=20 > > > fc: c5 f8 77 vzeroupper=20 > > > ff: c3 ret=20=20=20=20 > >=20 > > Btw, if the 'je' mispredicts to the vzeroupper case inside an transacti= on > > will the speculative execution of vzeroupper abort the transaction or > > does it only abort the transaction when retired? >=20 > My branch includes RTM test: >=20 > for (i =3D 0; i < loop; i++) > { > if (_xbegin() =3D=3D _XBEGIN_STARTED) > { > failed |=3D function (); > _xend(); > } > else > { > failed |=3D function (); > ++naborts; > } > } >=20 > It passes with xtest + je. that's good to hear. Does it still work when you add and unconditional non-transaction failed |=3D function (); before the loop? Just trying to make sure we do actually mispredict the xtest + je. --=20 You are receiving this mail because: You are on the CC list for the bug.=