[Bug ipa/116410] New: fat-lto-objects generates different and inefficient code compared with no-fat-lto-objects

[Bug ipa/116410] New: fat-lto-objects generates different and inefficient code compared with no-fat-lto-objects

[yinyuefengyi at gmail dot com]

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

            Bug ID: 116410
           Summary: fat-lto-objects generates different and inefficient
                    code compared with no-fat-lto-objects
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yinyuefengyi at gmail dot com
  Target Milestone: ---

It seems unexpected that -ffat-lto-objects generates different code compared
with -fno-fat-lto-objects (which is set by default in GCC).  Unfortunately is
-ffat-lto-objects produces code with worse performance compared with
-fno-fat-lto-objects by about 2%+.  Even worse, many release OS like
Fedora/Redhat added the flag -ffat-lto-objects as global flag when building the
OSes, which means all software packages build by it are slow down.

One typical example is found in zstd and could be reproduced as below:


git clone https://github.com/facebook/zstd.git

cd zstd/programs
export CFLAGS="-O2 -flto=auto -g"
make zstd V=1 -j
gdb -batch -ex "disassemble/r ZSTD_rescaleFreqs" zstd   > nofat.asm

export CFLAGS="-O2 -flto=auto -g -ffat-lto-objects"
gdb -batch -ex "disassemble/r ZSTD_rescaleFreqs" zstd > fat.asm


cut one piece of code from fat-lto-objects:

   0x000000000043aca3 <+99>:    0f 29 54 24 10  movaps %xmm2,0x10(%rsp)
   0x000000000043aca8 <+104>:   0f 29 04 24     movaps %xmm0,(%rsp)
   0x000000000043acac <+108>:   0f 29 54 24 20  movaps %xmm2,0x20(%rsp)
   0x000000000043acb1 <+113>:   0f 29 54 24 30  movaps %xmm2,0x30(%rsp)
   0x000000000043acb6 <+118>:   0f 29 54 24 40  movaps %xmm2,0x40(%rsp)
   0x000000000043acbb <+123>:   0f 29 54 24 50  movaps %xmm2,0x50(%rsp)
   0x000000000043acc0 <+128>:   0f 29 54 24 60  movaps %xmm2,0x60(%rsp)
   0x000000000043acc5 <+133>:   0f 29 54 24 70  movaps %xmm2,0x70(%rsp)
   0x000000000043acca <+138>:   0f 29 94 24 80 00 00 00 movaps %xmm2,0x80(%rsp)
   0x000000000043acd2 <+146>:   0f 11 00        movups %xmm0,(%rax)
   0x000000000043acd5 <+149>:   66 0f 6f 7c 24 10       movdqa 0x10(%rsp),%xmm7
   0x000000000043acdb <+155>:   66 0f ef c0     pxor   %xmm0,%xmm0
   0x000000000043acdf <+159>:   0f 11 78 10     movups %xmm7,0x10(%rax)
   0x000000000043ace3 <+163>:   66 0f 6f 7c 24 20       movdqa 0x20(%rsp),%xmm7
   0x000000000043ace9 <+169>:   0f 11 78 20     movups %xmm7,0x20(%rax)
   0x000000000043aced <+173>:   66 0f 6f 7c 24 30       movdqa 0x30(%rsp),%xmm7
   0x000000000043acf3 <+179>:   0f 11 78 30     movups %xmm7,0x30(%rax)
   0x000000000043acf7 <+183>:   66 0f 6f 7c 24 40       movdqa 0x40(%rsp),%xmm7
   0x000000000043acfd <+189>:   0f 11 78 40     movups %xmm7,0x40(%rax)
   0x000000000043ad01 <+193>:   66 0f 6f 7c 24 50       movdqa 0x50(%rsp),%xmm7
   0x000000000043ad07 <+199>:   0f 11 78 50     movups %xmm7,0x50(%rax)
   0x000000000043ad0b <+203>:   66 0f 6f 74 24 60       movdqa 0x60(%rsp),%xmm6
   0x000000000043ad11 <+209>:   0f 11 70 60     movups %xmm6,0x60(%rax)
   0x000000000043ad15 <+213>:   66 0f 6f 7c 24 70       movdqa 0x70(%rsp),%xmm7
   0x000000000043ad1b <+219>:   0f 11 78 70     movups %xmm7,0x70(%rax)



same piece of code from no-fat-lto-objects:

   0x000000000043ab03 <+99>:    0f 11 50 10     movups %xmm2,0x10(%rax)
   0x000000000043ab07 <+103>:   0f 11 00        movups %xmm0,(%rax)
   0x000000000043ab0a <+106>:   0f 29 04 24     movaps %xmm0,(%rsp)
   0x000000000043ab0e <+110>:   66 0f ef c0     pxor   %xmm0,%xmm0
   0x000000000043ab12 <+114>:   0f 11 50 20     movups %xmm2,0x20(%rax)
   0x000000000043ab16 <+118>:   0f 11 50 30     movups %xmm2,0x30(%rax)
   0x000000000043ab1a <+122>:   0f 11 50 40     movups %xmm2,0x40(%rax)
   0x000000000043ab1e <+126>:   0f 11 50 50     movups %xmm2,0x50(%rax)
   0x000000000043ab22 <+130>:   0f 11 50 60     movups %xmm2,0x60(%rax)
   0x000000000043ab26 <+134>:   0f 11 50 70     movups %xmm2,0x70(%rax)
   0x000000000043ab2a <+138>:   0f 11 90 80 00 00 00    movups %xmm2,0x80(%rax)
   0x000000000043ab31 <+145>:   48 89 e0        mov    %rsp,%rax
   0x000000000043ab34 <+148>:   0f 29 54 24 10  movaps %xmm2,0x10(%rsp)
   0x000000000043ab39 <+153>:   0f 29 54 24 20  movaps %xmm2,0x20(%rsp)
   0x000000000043ab3e <+158>:   0f 29 54 24 30  movaps %xmm2,0x30(%rsp)
   0x000000000043ab43 <+163>:   0f 29 54 24 40  movaps %xmm2,0x40(%rsp)
   0x000000000043ab48 <+168>:   0f 29 54 24 50  movaps %xmm2,0x50(%rsp)
   0x000000000043ab4d <+173>:   0f 29 54 24 60  movaps %xmm2,0x60(%rsp)
   0x000000000043ab52 <+178>:   0f 29 54 24 70  movaps %xmm2,0x70(%rsp)
   0x000000000043ab57 <+183>:   0f 29 94 24 80 00 00 00 movaps %xmm2,0x80(%rsp)
   0x000000000043ab5f <+191>:   90      nop



I did a initial investigation and found that summaries information become
different since ipa-moderef pass:


  /* Compute no-LTO summaries when local optimization is going to happen.  */
  bool nolto = (!ipa || ((!flag_lto || flag_fat_lto_objects) && !in_lto_p)
                || (in_lto_p && !flag_wpa
                    && flag_incremental_link != INCREMENTAL_LINK_LTO));


nolto is true for fat-lto-objects, but false for no-fat-lto-objects, then
followed summary/summaries are modified and caused different alias analysis
information, dse fail to remove the redudant load/store to stack.  Is this a
valid bug?

[Bug ipa/116410] fat-lto-objects generates different and inefficient code compared with no-fat-lto-objects

[yinyuefengyi at gmail dot com]

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

--- Comment #1 from Xionghu Luo (luoxhu at gcc dot gnu.org) <yinyuefengyi at gmail dot com> ---
Created attachment 58950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58950&action=edit
nofat.asm for ZSTD_rescaleFreqs

[Bug ipa/116410] fat-lto-objects generates different and inefficient code compared with no-fat-lto-objects

[yinyuefengyi at gmail dot com]

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

--- Comment #2 from Xionghu Luo (luoxhu at gcc dot gnu.org) <yinyuefengyi at gmail dot com> ---
Created attachment 58951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58951&action=edit
fat.asm for ZSTD_rescaleFreqs

[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|richard.guenther at gmail dot com  |rguenth at gcc dot gnu.org
           Keywords|                            |missed-optimization
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-08-19
            Summary|fat-lto-objects generates   |-ffat-lto-objects generates
                   |different and inefficient   |different and inefficient
                   |code compared with          |code compared with
                   |no-fat-lto-objects          |-fno-fat-lto-objects
            Version|11.0                        |15.0

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's a bit weird we have both 'nolto' and 'lto' vars, I also have no idea how
LTO and non-LTO IPA summaries would differ?

Honza will know.

[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects

[yinyuefengyi at gmail dot com]

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

--- Comment #4 from Xionghu Luo (luoxhu at gcc dot gnu.org) <yinyuefengyi at gmail dot com> ---
Gimple code:

  <bb 33> [local count: 19864224]:
  MEM <vector(4) unsigned int> [(unsigned int *)&baseLLfreqs] = { 4, 2, 1, 1 };
  MEM <vector(4) unsigned int> [(unsigned int *)&baseLLfreqs + 16B] = { 1, 1,
1, 1 };
  MEM <vector(4) unsigned int> [(unsigned int *)&baseLLfreqs + 32B] = { 1, 1,
1, 1 };
  MEM <vector(4) unsigned int> [(unsigned int *)&baseLLfreqs + 48B] = { 1, 1,
1, 1 };
  MEM <vector(4) unsigned int> [(unsigned int *)&baseLLfreqs + 64B] = { 1, 1,
1, 1 };
  MEM <vector(4) unsigned int> [(unsigned int *)&baseLLfreqs + 80B] = { 1, 1,
1, 1 };
  MEM <vector(4) unsigned int> [(unsigned int *)&baseLLfreqs + 96B] = { 1, 1,
1, 1 };
  MEM <vector(4) unsigned int> [(unsigned int *)&baseLLfreqs + 112B] = { 1, 1,
1, 1 };
  MEM <vector(4) unsigned int> [(unsigned int *)&baseLLfreqs + 128B] = { 1, 1,
1, 1 };
  _49 = optPtr_83(D)->litLengthFreq;
  __builtin_memcpy (_49, &baseLLfreqs, 144);    //   <=
  ivtmp.401_149 = (unsigned long) &baseLLfreqs;
  _146 = ivtmp.401_149 + 144;


Obviously, the __builtin_memcpy is not optimized as expected when built with
fat-lto-objects.

[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 59016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59016&action=edit
A patch

Please try this.

[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661631.html

[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects

[yinyuefengyi at gmail dot com]

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

--- Comment #7 from Xionghu Luo (luoxhu at gcc dot gnu.org) <yinyuefengyi at gmail dot com> ---
(In reply to H.J. Lu from comment #5)
> Created attachment 59016 [details]
> A patch
> 
> Please try this.


Thanks, it works.

[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects

[sjames at gcc dot gnu.org]

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

--- Comment #8 from Sam James <sjames at gcc dot gnu.org> ---
We plan to adopt -ffat-lto-objects ourselves soon for at least a subset of
packages, so this was good timing. :)

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's also effectively a regression, isn't it?  When was the problematical 'else
if' introduced?

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[sjames at gcc dot gnu.org]

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

--- Comment #10 from Sam James <sjames at gcc dot gnu.org> ---
r11-5517-g3350e59f298546 and r11-5061-g85ebbabd85e03b, but we added modref in
r11-3308-gd119f34c952f87 (so it was broken from the start)

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[hubicka at ucw dot cz]

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

--- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> ---
> We plan to adopt -ffat-lto-objects ourselves soon for at least a subset of
> packages, so this was good timing. :)
Note that -ffat-lto-objects has various issues, especially with library
archives.  The problem is that fat LTO object has two symbol tables (one
ELF and one LTO) but ar and other utilities does not handle this and
will pick one of the two symbol tables. In the case the symbol LTO and
non-LTO symbol tables diverge, surprises happens.
HJ had binutils patch solving this, but AFAIK it was not merged in.

Honza

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:2f1689ea8e631ebb4ff3720d56ef0362f5898ff6

commit r15-3416-g2f1689ea8e631ebb4ff3720d56ef0362f5898ff6
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Aug 27 13:11:39 2024 -0700

    ipa: Don't disable function parameter analysis for fat LTO

    Update analyze_parms not to disable function parameter analysis for
    -ffat-lto-objects.  Tested on x86-64, there are no differences in zstd
    with "-O2 -flto=auto" -g "vs -O2 -flto=auto -g -ffat-lto-objects".

            PR ipa/116410
            * ipa-modref.cc (analyze_parms): Always analyze function parameter
            for LTO.

    Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[sjames at gcc dot gnu.org]

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

--- Comment #13 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #11)
> > We plan to adopt -ffat-lto-objects ourselves soon for at least a subset of
> > packages, so this was good timing. :)
> Note that -ffat-lto-objects has various issues, especially with library
> archives.  The problem is that fat LTO object has two symbol tables (one
> ELF and one LTO) but ar and other utilities does not handle this and
> will pick one of the two symbol tables. In the case the symbol LTO and
> non-LTO symbol tables diverge, surprises happens.

OK, so we should only do it with care & selectively for packages which must
install static libraries (like flex).

> HJ had binutils patch solving this, but AFAIK it was not merged in.
> 

H.J., can I help with this at all?

> Honza

Thanks honza for the advice

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Sam James from comment #13)
> (In reply to Jan Hubicka from comment #11)
> > > We plan to adopt -ffat-lto-objects ourselves soon for at least a subset of
> > > packages, so this was good timing. :)
> > Note that -ffat-lto-objects has various issues, especially with library
> > archives.  The problem is that fat LTO object has two symbol tables (one
> > ELF and one LTO) but ar and other utilities does not handle this and
> > will pick one of the two symbol tables. In the case the symbol LTO and
> > non-LTO symbol tables diverge, surprises happens.
> 
> OK, so we should only do it with care & selectively for packages which must
> install static libraries (like flex).
> 
> > HJ had binutils patch solving this, but AFAIK it was not merged in.
> > 
> 
> H.J., can I help with this at all?

Here is the patch set:

https://patchwork.sourceware.org/project/binutils/list/?series=38121

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:6abedee0d4c8d40d412a358a3f6cb6090772d286

commit r14-10647-g6abedee0d4c8d40d412a358a3f6cb6090772d286
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Aug 27 13:11:39 2024 -0700

    ipa: Don't disable function parameter analysis for fat LTO

    Update analyze_parms not to disable function parameter analysis for
    -ffat-lto-objects.  Tested on x86-64, there are no differences in zstd
    with "-O2 -flto=auto" -g "vs -O2 -flto=auto -g -ffat-lto-objects".

            PR ipa/116410
            * ipa-modref.cc (analyze_parms): Always analyze function parameter
            for LTO.

    Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
    (cherry picked from commit 2f1689ea8e631ebb4ff3720d56ef0362f5898ff6)

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:e83df98c8142235cda0bcd538907a4693e420c92

commit r13-9006-ge83df98c8142235cda0bcd538907a4693e420c92
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Aug 27 13:11:39 2024 -0700

    ipa: Don't disable function parameter analysis for fat LTO

    Update analyze_parms not to disable function parameter analysis for
    -ffat-lto-objects.  Tested on x86-64, there are no differences in zstd
    with "-O2 -flto=auto" -g "vs -O2 -flto=auto -g -ffat-lto-objects".

            PR ipa/116410
            * ipa-modref.cc (analyze_parms): Always analyze function parameter
            for LTO.

    Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
    (cherry picked from commit 2f1689ea8e631ebb4ff3720d56ef0362f5898ff6)

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:42d4aa02c6016cc8efd896f627f692896e68c914

commit r12-10699-g42d4aa02c6016cc8efd896f627f692896e68c914
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Aug 27 13:11:39 2024 -0700

    ipa: Don't disable function parameter analysis for fat LTO

    Update analyze_parms not to disable function parameter analysis for
    -ffat-lto-objects.  Tested on x86-64, there are no differences in zstd
    with "-O2 -flto=auto" -g "vs -O2 -flto=auto -g -ffat-lto-objects".

            PR ipa/116410
            * ipa-modref.cc (analyze_parms): Always analyze function parameter
            for LTO.

    Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
    (cherry picked from commit 2f1689ea8e631ebb4ff3720d56ef0362f5898ff6)

[Bug ipa/116410] modref doesn't generate LTO summaries with -ffat-lto-objects (-ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects)

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |12.5

--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed for GCC 15, GCC 14.3, GCC 13.4 and GCC 12.5.