[Bug tree-optimization/105643] New: [13 Regression] Code-Size regression for specrate 538.imagick_r

[Bug tree-optimization/105643] New: [13 Regression] Code-Size regression for specrate 538.imagick_r

[admin at levyhsu dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

            Bug ID: 105643
           Summary: [13 Regression] Code-Size regression for specrate
                    538.imagick_r
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: admin at levyhsu dot com
  Target Milestone: ---

We found on Intel platform, commit r13-128-g938a02a589dc22
(938a02a589dc22cef65bba2b131fc9e4874baddb) results 53.7% codesize increment
when compiled with march_native_ofast_lto(-march=native -Ofast -funroll-loops
-flto) for specrate 538.imagick_r on SkylakeW, Cascade Lake and IceLake.

On Zen3 Server/Client code size looks alright.

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>From what I know, that might be the loop versioning for alias or otherwise
kicking in more since the vectorizer can not vectorize more loops.

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |13.0

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Odd indeed.  All archs enable AVX512, it would be interesting to see if with
-fopt-info-vec indeed many more loops are vectorized and whether it also
reproduces without -flto and affects mostly a single TU?

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-05-18
                 CC|                            |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1
             Blocks|                            |26163
             Status|UNCONFIRMED                 |NEW


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[admin at levyhsu dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

--- Comment #3 from Levy Hsu <admin at levyhsu dot com> ---
I forgot to mention, that the build time also increased by 128% on the Intel
platform above, but no performance improvement was spotted.

I'll check the objdump and see what happens.

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[admin at levyhsu dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

--- Comment #4 from Levy Hsu <admin at levyhsu dot com> ---
Created attachment 52995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52995&action=edit
-fopt-info-vec before that commit

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[admin at levyhsu dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

--- Comment #5 from Levy Hsu <admin at levyhsu dot com> ---
Created attachment 52996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52996&action=edit
-fopt-info-vec after this commit

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[admin at levyhsu dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

--- Comment #6 from Levy Hsu <admin at levyhsu dot com> ---
Created attachment 52997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52997&action=edit
Vec different seems to related SetPixelPacket

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
It seems there are a lot of loops like the following in FrameImage

            for (x=0; x < (ssize_t) width; x++)
            {
              SetPixelPacket(frame_image,&matte,q,frame_indexes);
              q++;
              frame_indexes++;
            }

and they are now vectorized with an alias runtime check and a vectorized
epilogue.  I'd say that's good.  The "bad" is that we are unswitching
all those loops twice:

magick/decorate.c:605:25: optimized: Unswitching loop on condition: _1874 <=
0.0
magick/decorate.c:605:25: optimized: Unswitching loop on condition: _1874 >=
6.5535e+4

which means we have three copies to vectorize at least.  Doesn't really
explain your opt-info reports reporting :605 16 times.

In fact, I don't see any vectorization with -march=skylake-avx512 here
(but I didn't use -funroll-loops which will only make a difference on RTL
so generally I'd avoid that).  Maybe I need to check with a compiler
that doesn't have some unswitching improvements queued (but the old should get
those opportunities as well I think).

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

--- Comment #8 from Hongtao.liu <crazylht at gmail dot com> ---
Looks like codesize decreased after
r13-754-ga1c9f779f75283427316b5c670c1e01ff8ce9ced.

Now we have cost model for unswitching loop

decorate.c:605:25: note: not unswitching condition, cost too big (37 insns
copied to 35 and 37)

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 31 May 2022, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
> 
> --- Comment #8 from Hongtao.liu <crazylht at gmail dot com> ---
> Looks like codesize decreased after
> r13-754-ga1c9f779f75283427316b5c670c1e01ff8ce9ced.
> 
> Now we have cost model for unswitching loop
> 
> decorate.c:605:25: note: not unswitching condition, cost too big (37 insns
> copied to 35 and 37)

Yes, I noticed that when comparing opt-info before/after on SPEC as
well.  Note the actual cost limit wasn't adjusted in any way, there's
still some planned improvements pending and adjusting the cost limit
is one of that.

[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed / wontfix further.