This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Enabling -ftree-slp-vectorize on -O2/Os
- From: Allan Sandfeld Jensen <linux at carewolf dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 27 May 2018 12:26:46 +0200
- Subject: Re: Enabling -ftree-slp-vectorize on -O2/Os
- References: <2659301.XPQk3P0qmd@twilight> <20109354.MqXXt4BNHg@twilight> <20180527012336.GU17342@gate.crashing.org>
On Sonntag, 27. Mai 2018 03:23:36 CEST Segher Boessenkool wrote:
> On Sun, May 27, 2018 at 01:25:25AM +0200, Allan Sandfeld Jensen wrote:
> > On Sonntag, 27. Mai 2018 00:05:32 CEST Segher Boessenkool wrote:
> > > On Sat, May 26, 2018 at 11:32:29AM +0200, Allan Sandfeld Jensen wrote:
> > > > I brought this subject up earlier, and was told to suggest it again
> > > > for
> > > > gcc 9, so I have attached the preliminary changes.
> > > >
> > > > My studies have show that with generic x86-64 optimization it reduces
> > > > binary size with around 0.5%, and when optimizing for x64 targets with
> > > > SSE4 or better, it reduces binary size by 2-3% on average. The
> > > > performance changes are negligible however*, and I haven't been able
> > > > to
> > > > detect changes in compile time big enough to penetrate general noise
> > > > on
> > > > my platform, but perhaps someone has a better setup for that?
> > > >
> > > > * I believe that is because it currently works best on non-optimized
> > > > code,
> > > > it is better at big basic blocks doing all kinds of things than
> > > > tightly
> > > > written inner loops.
> > > >
> > > > Anythhing else I should test or report?
> > >
> > > What does it do on other architectures?
> >
> > I believe NEON would do the same as SSE4, but I can do a check. For
> > architectures without SIMD it essentially does nothing.
>
> Sorry, I wasn't clear. What does it do to performance on other
> architectures? Is it (almost) always a win (or neutral)? If not, it
> doesn't belong in -O2, not for the generic options at least.
>
It shouldnt have any way of making slower code, so it is neutral or a win in
performance, and similarly in code size, merged instructions means fewer
instructions.
I never found a benchmark where it really made a measurable difference in
performance, but I found many large binaries such as Qt or Chromium, where it
made the binaries a few percent smaller.
Allan