This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: loading of zeros into {x,y,z}mm registers
- From: "Shalnov, Sergey" <sergey dot shalnov at intel dot com>
- To: Jan Beulich <JBeulich at suse dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 6 Dec 2017 08:49:57 +0000
- Subject: RE: loading of zeros into {x,y,z}mm registers
- Authentication-results: sourceware.org; auth=none
- Dlp-product: dlpe-windows
- Dlp-reaction: no-action
- Dlp-version: 11.0.0.116
- References: <5A1EE7890200007800193391@prv-mh.provo.novell.com>
Jan,
In case of AVX512 we need to support higher vector registers. We have to work with xmm16-xmm31 in this case.
Sergey
-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Jan Beulich
Sent: Wednesday, November 29, 2017 5:00 PM
To: Kirill Yukhin <kirill.yukhin@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: loading of zeros into {x,y,z}mm registers
Kirill,
in an unrelated context I've stumbled across a change of yours from Aug 2014 (revision 213847) where you "extend" the ways of loading zeros into registers. I don't understand why this was done, and the patch submission mail also doesn't give any reason.
My point is that simple VEX-encoded vxorps/vxorpd/vpxor with 128-bit register operands ought to be sufficient to zero any width registers, due to the zeroing of the high parts the instructions do.
Hence by using EVEX encoded insns it looks like all you do is grow the instruction length by one or two bytes (besides making the source somewhat more complicated to follow). At the very least the shorter variants should be used for -Os imo.
Thanks for any insight,
Jan