[x86_64 PATCH] Tweak -Os costs for scalar-to-vector pass.

Roger Sayle roger@nextmovesoftware.com
Tue Aug 24 02:08:45 GMT 2021

Many thanks.  Here’s the version that I've committed with a ??? comment as
requested (even a no-op else clause to make the logic easier to understand).

2021-08-24  Roger Sayle  <roger@nextmovesoftware.com>
	    Richard Biener  <rguenther@suse.de>

	* config/i386/i386-features.c (compute_convert_gain): Provide
	more accurate values for CONST_INT, when optimizing for size.
	* config/i386/i386.c (COSTS_N_BYTES): Move definition from here...
	* config/i386/i386.h (COSTS_N_BYTES): to here.


-----Original Message-----
From: Richard Biener <richard.guenther@gmail.com> 
Sent: 23 August 2021 14:47
To: Roger Sayle <roger@nextmovesoftware.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [x86_64 PATCH] Tweak -Os costs for scalar-to-vector pass.

On Fri, Aug 20, 2021 at 9:55 PM Roger Sayle <roger@nextmovesoftware.com> wrote:
> Hi Richard,
> Benchmarking this patch using CSiBE on x86_64-pc-linux-gnu with -Os -m32 saves 2432 bytes.
> Of the 893 tests, 34 have size differences, 30 are improvements, 4 are regressions (of a few bytes).
> > Also I'm missing a 'else' - in the default case there's no cost/benefit of using SSE vs. GPR regs?
> > For SSE it would be a constant pool load.
> The code size regression  I primarily wanted to tackle was the zero 
> vs. non-zero case when dealing with immediate operands, which was the 
> piece affected by my and Jakub's xor improvements.
> Alas my first attempt to specify a non-zero gain in the default 
> (doesn't fit in SImode) case, increased the code size slightly.  The 
> use of the constant pool complicates things, as the number of times 
> the same value is used becomes an issue.  If the constant being loaded 
> is unique, then clearly the increase in constant pool size should 
> (ideally) be taken into account.  But if the same constant is used 
> multiple times in a chain (or is already in the constant pool), the 
> observed cost is much cheaper.  Empirically, a value of zero isn't a 
> poor choice, so the decision on whether to use vector instructions is shifted to the gains from operations being performed, rather than the loading of integer constants.  No doubt, like rtx_costs, these are free parameters that future generations will continue to tweak and refine.
> Given that this patch reduces code size with -Os, both with and without -m32, ok for mainline?

OK if you add a comment for the missing 'else'.


> Thanks in advance,
> Roger
> --

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patchz2.txt
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210824/57aa078c/attachment.txt>

More information about the Gcc-patches mailing list