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: Richard Biener <richard dot guenther at gmail dot com>
- To: Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Cc: Jan Beulich <JBeulich at suse dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 1 Dec 2017 12:44:29 +0100
- Subject: Re: loading of zeros into {x,y,z}mm registers
- Authentication-results: sourceware.org; auth=none
- References: <5A1EE7890200007800193391@prv-mh.provo.novell.com> <20171201054550.GA22657@titus>
On Fri, Dec 1, 2017 at 6:45 AM, Kirill Yukhin <kirill.yukhin@gmail.com> wrote:
> Hello Jan,
> On 29 Nov 08:59, Jan Beulich wrote:
>> 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.
> As far as I can recall, this was done since we cannot load zeroes
> into upper 16 MM registers, which are available in EVEX exclusively.
Note on Zen pxor on %ymm also takes double amount of resources
as that on %xmm.
It would be nice to fix this (and maybe also factor the ability to
reference upper 16 MM regs in costing during RA ...?).
Richard.
>>
>> Thanks for any insight,
>> Jan
>>
>
> --
> Thanks, K