[Bug ipa/65701] New: r221530 makes 187.facerec drop with -Ofast -flto

[Bug ipa/65701] New: r221530 makes 187.facerec drop with -Ofast -flto

[rguenth at gcc dot gnu.org]

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

            Bug ID: 65701
           Summary: r221530 makes 187.facerec drop with -Ofast -flto
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: lto, missed-optimization
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
                CC: hubicka at gcc dot gnu.org

+2015-03-20  Jan Hubicka  <hubicka@ucw.cz>
+
+       * ipa-inline.c (can_inline_edge_p): Short circuit if inline_failed
+       already is final.
+       (ipa_inline): Recompute inline_failed codes.
+       * cif-code.def (FUNCTION_NOT_OPTIMIZED, REDEFINED_EXTERN_INLINE,
+       USES_COMDAT_LOCAL, ATTRIBUTE_MISMATCH, UNREACHABLE): Declare as 
+       CIF_FINAL_ERROR.

makes 187.facerec drop in
http://gcc.opensuse.org/SPEC/CFP/sb-megrez-head-64/recent.html, but only for
LTO.

revision range is 221529 (good) 221531 (bad).

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
-Ofast -march=native, that is.  (which may be the key to the issue?)

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
build log

/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
FaceRecTypes.o              -Ofast -march=native -flto=8 -fno-fat-lto-objects 
FaceRecTypes.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
parameterRoutines.o              -Ofast -march=native -flto=8
-fno-fat-lto-objects  parameterRoutines.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
cfftb.o              -Ofast -march=native -flto=8 -fno-fat-lto-objects 
cfftb.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
cfftf.o              -Ofast -march=native -flto=8 -fno-fat-lto-objects 
cfftf.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
cffti.o              -Ofast -march=native -flto=8 -fno-fat-lto-objects 
cffti.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
fft2d.o              -Ofast -march=native -flto=8 -fno-fat-lto-objects 
fft2d.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
gaborRoutines.o              -Ofast -march=native -flto=8 -fno-fat-lto-objects 
gaborRoutines.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
imageRoutines.o              -Ofast -march=native -flto=8 -fno-fat-lto-objects 
imageRoutines.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
graphRoutines.o              -Ofast -march=native -flto=8 -fno-fat-lto-objects 
graphRoutines.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o
FaceRec.o              -Ofast -march=native -flto=8 -fno-fat-lto-objects 
FaceRec.f90
/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran
-Wl,-rpath=/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/lib64     
-Ofast -march=native -flto=8 -fno-fat-lto-objects  FaceRecTypes.o
parameterRoutines.o cfftb.o cfftf.o cffti.o fft2d.o gaborRoutines.o
imageRoutines.o graphRoutines.o FaceRec.o     -o facerec

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Yep, I looked into this regression a bit.  The patch just avoids some "false
positives" of inlining functions called once (i.e. case where we think the
function will optimize out but it really won't so we end up with duplication)
and also some "false negatives".
As such, it can affect pretty large functions to be or not be inlined. I will
oprofile to figure out which one it is here.

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-09
     Ever confirmed|0                           |1

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The difference in inlining decision is 
(- is with patch reverted, + is current mainline):

 Why inlining failed?
-function body not available                       :      568 calls,  4150392
freq, 0 count
---param large-function-growth limit reached       :        3 calls,     3000
freq, 0 count
+function body not available                       :      568 calls,  3750333
freq, 0 count
+--param large-function-growth limit reached       :        2 calls,   101000
freq, 0 count
 --param large-stack-frame-growth limit reached    :        1 calls,     1000
freq, 0 count
---param max-inline-insns-auto limit reached       :       37 calls,   265369
freq, 0 count
+--param max-inline-insns-auto limit reached       :       37 calls,   275141
freq, 0 count

that actually means a lot of changes in the particular inlining decisions,
because several large functions gets inlined differently.

The beggining of inline changes seems as expected - the growths are corrected
on mainline and thus we start considering functions in different order.

I will need to profile this

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The profile difference is:

 52.31%  facerec  facerec            [.] MAIN__.lto_priv.3                     
                                                                               
                           �
 16.68%  facerec  facerec            [.] topcostfct.3487.lto_priv.4            
                                                                               
                           �
  8.28%  facerec  facerec            [.] __gaborroutines_MOD_gabortrafo        
                                                                               
                           �
  7.91%  facerec  facerec            [.] cfftb_                                
                                                                               
                           �
  7.20%  facerec  libgfortran.so.3   [.] _gfortrani_cshift0_r4                 
                                                                               
                           �
  2.76%  facerec  facerec            [.] __fft2d_MOD_fft2db                    
                                                                               
                           �
  1.54%  facerec  facerec            [.]
__graphroutines_MOD_graphsimfct.constprop.0                                    
                                                                  �
  0.53%  facerec  libc-2.13.so       [.] __memcpy_ssse3                        
                                                                               
                           �

(mainline) WRT

 59.16%  facerec  facerec            [.] MAIN__.lto_priv.3                     
                                                                               
                           �
 10.95%  facerec  facerec            [.] __gaborroutines_MOD_gabortrafo        
                                                                               
                           �
 10.51%  facerec  facerec            [.] cfftb1_                               
                                                                               
                           �
  9.33%  facerec  libgfortran.so.3   [.] _gfortrani_cshift0_r4                 
                                                                               
                           �
  3.64%  facerec  facerec            [.] __fft2d_MOD_fft2db                    
                                                                               
                           �
  2.07%  facerec  facerec            [.]
__graphroutines_MOD_graphsimfct.constprop.0                                    
                                                                  �
  0.67%  facerec  libc-2.13.so       [.] __memcpy_ssse3                        
                                                                               
                           �
  0.57%  facerec  libgfortran.so.3   [.] _gfortrani_read_radix                 
                                                                               
                           �
  0.43%  facerec  libgcc_s.so.1      [.] __udivti3                             
                                                                               
                           �
  0.36%  facerec  libgfortran.so.3   [.] formatted_transfer                    
                                                                               
                           �
patch reverted. I wonder if we don't want to iline udivti... I suppose the
problem is that we no longer inline topcostfct which we do not inline
because...

not inlinable: localmove.constprop/304 -> topcostfct/208, --param
large-function-growth limit reached

while patched tree suceeds:

Inlining topcostfct size 1393.
 Called once from localmove.constprop 740 insns.
                Accounting size:1132.00, time:12187.80 on predicate:(true)

Bumping the large-function-insns limit up to 4000 makes the function to be
inlined but curiously enough causes further degradation. The profile is now:

66.35%  facerec  facerec            [.] MAIN__.lto_priv.3                      
                                                                               
                          �
  8.93%  facerec  facerec            [.] __gaborroutines_MOD_gabortrafo        
                                                                               
                           �
  8.72%  facerec  facerec            [.] cfftb_                                
                                                                               
                           �
  7.77%  facerec  libgfortran.so.3   [.] _gfortrani_cshift0_r4                 
                                                                               
                           �
  2.96%  facerec  facerec            [.] __fft2d_MOD_fft2db                    
                                                                               
                           �
  1.68%  facerec  facerec            [.]
__graphroutines_MOD_graphsimfct.constprop.0                                    
                                                                  �
  0.55%  facerec  libc-2.13.so       [.] __memcpy_ssse3                        
                                                                               
                           �
  0.47%  facerec  libgfortran.so.3   [.] _gfortrani_read_radix                 
                                                                               
                           �
  0.34%  facerec  libgcc_s.so.1      [.] __udivti3                             
                                                                               
                           �
  0.30%  facerec  libgfortran.so.3   [.] formatted_transfer                    
                                                                               
                           �
  0.22%  facerec  libgfortran.so.3   [.] next_format0                          
                                                                               
                           �
  0.22%  facerec  facerec            [.] cfftf_                                
                                                                               
                           �
  0.20%  facerec  libgfortran.so.3   [.] _gfortrani_read_block_form            
                                                                               
                           �
so basically identical except that mainline inlines cfftb1_ and the patched
tree inlines cfftb_ which is a wrapper. Perhaps the wrapper heuristics may be
generalized for this.
>From gcc-bugs-return-483062-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 09 04:50:22 2015
Return-Path: <gcc-bugs-return-483062-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 45056 invoked by alias); 9 Apr 2015 04:50:22 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 45005 invoked by uid 48); 9 Apr 2015 04:50:16 -0000
From: "michal.misiaszek at kofinder dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug gcov-profile/43341] pragma pack changes padding in struct gcov_info on 64-bit archs
Date: Thu, 09 Apr 2015 04:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: gcov-profile
X-Bugzilla-Version: 4.5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: michal.misiaszek at kofinder dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-43341-4-cbhV8gJfzw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-43341-4@http.gcc.gnu.org/bugzilla/>
References: <bug-43341-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg00614.txt.bz2
Content-length: 1501

https://gcc.gnu.org/bugzilla/show_bug.cgi?idC341

Michal Misiaszek <michal.misiaszek at kofinder dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michal.misiaszek at kofinder dot c
                   |                            |om

--- Comment #8 from Michal Misiaszek <michal.misiaszek at kofinder dot com> ---
Hi,
I was strglign for last 2 night with my aplication which generated coverage
files for all source files but one. At the end I found out that C++ file was
including .h file. If I commented out .h file then coverage was generated.
Only unusual thing I noticed was #pragma pack(1).
When I removed it the coverage was generated again !
Short search I found this bug. I can reproduce it all the time.
The version of g++ and gcov below
:
michal@ubuntu:~/git/blpr$ g++ --version
g++ (Ubuntu 4.9.1-16ubuntu6) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

michal@ubuntu:~/git/blpr$ gcov --version
gcov (Ubuntu 4.9.1-16ubuntu6) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.

Can you somehow patch it ?
Regards
Michal

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Strenghtening the wrapper heuristics:
Index: ipa-inline.c
===================================================================
--- ipa-inline.c        (revision 221909)
+++ ipa-inline.c        (working copy)
@@ -1124,8 +1124,8 @@ edge_badness (struct cgraph_edge *edge,
          /* ... and edges executed only conditionally ... */
          && edge->frequency < CGRAPH_FREQ_BASE
          /* ... consider case where callee is not inline but caller is ... */
-         && ((!DECL_DECLARED_INLINE_P (edge->callee->decl)
-              && DECL_DECLARED_INLINE_P (caller->decl))
+         && ((DECL_DECLARED_INLINE_P (edge->callee->decl)
+              <= DECL_DECLARED_INLINE_P (caller->decl))
              /* ... or when early optimizers decided to split and edge
                 frequency still indicates splitting is a win ... */
              || (callee->split_part && !caller->split_part

and bumping up the large-function-insns to 4000 makes the hot inline decisions
look the same. Still does not solve the benchmark. This time it seems that MAIN
got slower because we inlined more into it.

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, and setting --param large-function-insns=1000 gets the performance then.
The key seems to be in not inlining too much into main.  The hotspot change
from:

  1.11 �3682:   mov    0x60(%rsp),%rdx                                          
  9.32 �3687:���vmovss (%rax,%r12,2),%xmm5                                      
  1.44 �     �  vmovss (%rax),%xmm6                                             
  4.46 �     �  inc    %rdi                                                     
  0.01 �     �  add    $0x10,%rcx                                               
  1.17 �     �  vinser $0x10,(%rax,%r13,1),%xmm5,%xmm0                          
  1.92 �     �  vinser $0x10,(%rax,%r12,1),%xmm6,%xmm1                          
  0.28 �     �  add    %r14,%rax                                                
  0.07 �     �  vmovlh %xmm0,%xmm1,%xmm0                                        
  2.48 �     �  vfmadd %xmm3,-0x10(%rcx),%xmm0,%xmm3                            
  5.15 �     �  cmp    %rdi,%rdx                                                
  0.01 �     ���ja     3687                                                     
  1.21 �        vhaddp %xmm3,%xmm3,%xmm3                                        
 10.30 �        mov    0x58(%rsp),%rax                                          
  0.03 �        mov    %r13,0x10(%rsp)                                          
  0.00 �        add %rax,%rsi
  1.18 �        vhaddp %xmm3,%xmm3,%xmm3
 10.80 �        vaddss %xmm3,%xmm4,%xmm4                                        
  4.47 �        cmp    0x68(%rsp),%rax                                          

(the slower variant) to:

  1.38 �        xor    %ecx,%ecx                                                
  6.04 �17c0:���vmovss (%rax,%r11,2),%xmm3                                      
  0.18 �     �  mov    0x90(%rsp),%rsi                                          
  1.43 �     �  inc    %rcx                                                     
  1.42 �     �  vmovss (%rax),%xmm5                                             
  0.36 �     �  vmovss (%rdx,%rbx,2),%xmm6                                      
  2.81 �     �  vmovss (%rdx),%xmm7                                             
  0.90 �     �  vinser $0x10,(%rax,%rsi,1),%xmm3,%xmm2                          
  2.96 �     �  mov    0x88(%rsp),%rsi                                          
  0.04 �     �  vinser $0x10,(%rax,%r11,1),%xmm5,%xmm4                          
  2.76 �     �  add    0x70(%rsp),%rax                                          
  0.07 �     �  vinser $0x10,(%rdx,%rbx,1),%xmm7,%xmm3                          
  0.02 �     �  vmovlh %xmm2,%xmm4,%xmm4                                        
  2.69 �     �  vinser $0x10,(%rdx,%rsi,1),%xmm6,%xmm2                          
  1.13 �     �  add    0x78(%rsp),%rdx                                          
  0.04 �     �  vmovlh %xmm2,%xmm3,%xmm2                                        
  0.01 �     �  vfmadd %xmm0,%xmm2,%xmm4,%xmm0                                  
  2.74 �     �  cmp    %rcx,0x80(%rsp)                                          
  0.07 �     ���ja     17c0                                                     
  1.39 �        vhaddp %xmm0,%xmm0,%xmm0                                        
  4.45 �        mov    0x48(%rsp),%rsi                                          
  1.42 �        vhaddp %xmm0,%xmm0,%xmm0                                        
  7.96 �        vaddss %xmm0,%xmm1,%xmm1                                        
  4.09 �        cmp    %r15,0x60(%rsp)                                          
  0.01 �      � je     18b1                                                     

(the faster variant, dunno why)
>From gcc-bugs-return-483186-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 09 17:59:39 2015
Return-Path: <gcc-bugs-return-483186-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13617 invoked by alias); 9 Apr 2015 17:59:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13560 invoked by uid 55); 9 Apr 2015 17:59:35 -0000
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto
Date: Thu, 09 Apr 2015 17:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: lto, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at ucw dot cz
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65701-4-9xVJNKdaCo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65701-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65701-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg00738.txt.bz2
Content-length: 2237

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide701

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> ---
With spaces removed to be readable
>
>   1.11 ???3682:   mov    0x60(%rsp),%rdx
>   9.32 ???3687:?????????vmovss (%rax,%r12,2),%xmm5
>   1.44 ???     ???  vmovss (%rax),%xmm6
>   4.46 ???     ???  inc    %rdi
>   0.01 ???     ???  add    $0x10,%rcx
>   1.17 ???     ???  vinser $0x10,(%rax,%r13,1),%xmm5,%xmm0
>   1.92 ???     ???  vinser $0x10,(%rax,%r12,1),%xmm6,%xmm1
>   0.28 ???     ???  add    %r14,%rax
>   0.07 ???     ???  vmovlh %xmm0,%xmm1,%xmm0
>   2.48 ???     ???  vfmadd %xmm3,-0x10(%rcx),%xmm0,%xmm3
>   5.15 ???     ???  cmp    %rdi,%rdx
>   0.01 ???     ?????????ja     3687
>   1.21 ???        vhaddp %xmm3,%xmm3,%xmm3
>  10.30 ???        mov    0x58(%rsp),%rax
>   0.03 ???        mov    %r13,0x10(%rsp)
>   0.00 ???        add %rax,%rsi
>   1.18 ???        vhaddp %xmm3,%xmm3,%xmm3
>  10.80 ???        vaddss %xmm3,%xmm4,%xmm4
>   4.47 ???        cmp    0x68(%rsp),%rax
>
> (the slower variant) to:
>
>   1.38 ???        xor    %ecx,%ecx
>   6.04 ???17c0:?????????vmovss (%rax,%r11,2),%xmm3
>   0.18 ???     ???  mov    0x90(%rsp),%rsi
>   1.43 ???     ???  inc    %rcx
>   1.42 ???     ???  vmovss (%rax),%xmm5
>   0.36 ???     ???  vmovss (%rdx,%rbx,2),%xmm6
>   2.81 ???     ???  vmovss (%rdx),%xmm7
>   0.90 ???     ???  vinser $0x10,(%rax,%rsi,1),%xmm3,%xmm2
>   2.96 ???     ???  mov    0x88(%rsp),%rsi
>   0.04 ???     ???  vinser $0x10,(%rax,%r11,1),%xmm5,%xmm4
>   2.76 ???     ???  add    0x70(%rsp),%rax
>   0.07 ???     ???  vinser $0x10,(%rdx,%rbx,1),%xmm7,%xmm3
>   0.02 ???     ???  vmovlh %xmm2,%xmm4,%xmm4
>   2.69 ???     ???  vinser $0x10,(%rdx,%rsi,1),%xmm6,%xmm2
>   1.13 ???     ???  add    0x78(%rsp),%rdx
>   0.04 ???     ???  vmovlh %xmm2,%xmm3,%xmm2
>   0.01 ???     ???  vfmadd %xmm0,%xmm2,%xmm4,%xmm0
>   2.74 ???     ???  cmp    %rcx,0x80(%rsp)
>   0.07 ???     ?????????ja     17c0
>   1.39 ???        vhaddp %xmm0,%xmm0,%xmm0
>   4.45 ???        mov    0x48(%rsp),%rsi
>   1.42 ???        vhaddp %xmm0,%xmm0,%xmm0
>   7.96 ???        vaddss %xmm0,%xmm1,%xmm1
>   4.09 ???        cmp    %r15,0x60(%rsp)
>   0.01 ???      ??? je     18b1
>
> (the faster variant, dunno why)

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
To me it seems like more inlining enales us to SRA array descriptor that in
turn enables vectorizer to vectorize differently and slow down the code?

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenther at suse dot de,
                   |                            |vmakarov at redhat dot com

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
This is on clean mainline and bdver1 machine.

GCC with patch reverted runtime is:
real    0m50.714s
user    0m50.402s
sys     0m0.356s

and now with different inliner settings:

(talos4)$ sh compile

real    1m4.636s
user    1m4.270s
sys     0m0.420s
(talos4)$ sh compile --param large-function-insns=1000

real    0m51.063s
user    0m50.742s
sys     0m0.364s
(talos4)$ sh compile --param large-function-insns=100000 --param
large-stack-frame=100000

real    1m1.369s
user    1m1.012s
sys     0m0.407s
(talos4)$ sh compile -fno-tree-vectorize

real    1m0.629s
user    1m0.299s
sys     0m0.381s
(talos4)$ sh compile -fno-tree-vectorize --param large-function-insns=1000

real    0m53.375s
user    0m53.053s
sys     0m0.367s
(talos4)$ sh compile -fno-tree-vectorize --param large-function-insns=100000
--param large-stack-frame=100000

real    0m55.131s
user    0m54.826s
sys     0m0.351s

param large-function-insns=1000 is thus a winner, but apparently by an
accident.

It seems that tree vectorizer actually make code slower when more inlining and
SRA happens. Richard, perhaps with you vect-costmodel-fu, you can take a look?
It also may be just an RA issue, but I do not see particularly many spills in
ther internal loops.

To completely flatten the whole benchmark, one needs to also bump up
max-inline-insns-auto. This seems to firther degrade perofmrance with both
vectorizer and nonvectorizer, so it also may be just an register pressure and
IRA issue.

Richard, since it is the second time we run into large-function-insns being
beneficial, I wonder if you can patch frescobaldi or czerny (so we have c++
benchmark and LTO spec covered) with change of the parameter value?

The current value was never really tuned it is quite possibly just too large.
I will see if I can get anything useful out of firefox benchmarks.

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Also:
(talos4)$ sh compile  -fno-tree-sra

real    0m52.668s
user    0m52.365s
sys     0m0.348s

So it indeed looks like issue related to either vectorizer getting too fancy
with prior SRA or simply an register pressure issue.

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Ganesh.Gopalasubramanian@am
                   |                            |d.com

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
I notice some (obvious) differences (just glancing at -fopt-info)

graphRoutines.f90:393
graphRoutines.f90:359

are not peeled for alignment when vectorized in the good case.

But it seems that's ok (well, we're peeling too much for alignment IMHO...).
In the fast variant we vectorize strided loads while in the slow variant
we can use vector loads for one of the loads (and we made sure to use
aligned loads by peeling).

  1.11 �3682:   mov    0x60(%rsp),%rdx                                          
  9.32 �3687:���vmovss (%rax,%r12,2),%xmm5                                      
  1.44 �     �  vmovss (%rax),%xmm6                                             
  4.46 �     �  inc    %rdi                                                     
  0.01 �     �  add    $0x10,%rcx                                               
  1.17 �     �  vinser $0x10,(%rax,%r13,1),%xmm5,%xmm0                          
  1.92 �     �  vinser $0x10,(%rax,%r12,1),%xmm6,%xmm1                          
  0.28 �     �  add    %r14,%rax                                                
  0.07 �     �  vmovlh %xmm0,%xmm1,%xmm0                                        
  2.48 �     �  vfmadd %xmm3,-0x10(%rcx),%xmm0,%xmm3                            
  5.15 �     �  cmp    %rdi,%rdx                                                
  0.01 �     ���ja     3687                             

so maybe the vfmadd with a memory operand is just bad for the pipeline
(I suspect bad for the decoder at least).

To me it really looks like trunk generates better code but we run into
a very odd bdver2 architectural issue (if the above loop is really the issue).
You could try disabling peeling for alignment with --param
vect-max-peeling-for-alignment=0 (so you get unaligned load and a vfmadd
without memory operand).

I don't think this is a RA issue.

Ganesh?
>From gcc-bugs-return-483263-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 10 09:13:27 2015
Return-Path: <gcc-bugs-return-483263-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7372 invoked by alias); 10 Apr 2015 09:13:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7331 invoked by uid 48); 10 Apr 2015 09:13:23 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65728] template instantiation complains of sizeof failing due to incomplete definition
Date: Fri, 10 Apr 2015 09:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65728-4-axV464oWbH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65728-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65728-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg00815.txt.bz2
Content-length: 286

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide728

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Your testcase is invalid because it has an uninitialized reference member that
can never be initialized.

If you fix that, I think it should compile, so G++ is wrong.

[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Having two extra loops (prologue and epilogue) in the deep loop nest may be not
the best idea.

[Bug ipa/65701] [5 Regression] r221530 makes 187.facerec drop with -Ofast -flto on bdver2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*
   Target Milestone|---                         |5.0
            Summary|r221530 makes 187.facerec   |[5 Regression] r221530
                   |drop with -Ofast -flto      |makes 187.facerec drop with
                   |                            |-Ofast -flto on bdver2

[Bug ipa/65701] [5 Regression] r221530 makes 187.facerec drop with -Ofast -flto on bdver2

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
It would be nice to test it on AVX enabled intel CPU.  There are IMO at least
two things - first is the vectorizer oddity, second is that the fastest code
seems to happen with large-function-insns=1000.

I have no problem with adjusting this argument - it was largery unutuned for
years, but I would like to have some idea why the inlining hurts and if we can
fix that instead. Sadly the functions are quite big...

[Bug ipa/65701] [5/6 Regression] r221530 makes 187.facerec drop with -Ofast -flto on bdver2

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
However the spec score seems to indicate that well over half of the performance
gap is gone by the vectorizer change. Good ;)

[Bug ipa/65701] [5/6 Regression] r221530 makes 187.facerec drop with -Ofast -flto on bdver2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|5.0                         |5.2

[Bug ipa/65701] [5/6 Regression] r221530 makes 187.facerec drop with -Ofast -flto on bdver2

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Fri May 22 09:08:46 2015
New Revision: 223528

URL: https://gcc.gnu.org/viewcvs?rev=223528&root=gcc&view=rev
Log:
2015-05-22  Richard Biener  <rguenther@suse.de>

        PR tree-optimization/65701
        * tree-vect-data-refs.c (vect_enhance_data_refs_alignment):
        Move peeling cost models into one place.  Peel for alignment
        for single loads only if an aligned load is cheaper than
        an unaligned load.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-data-refs.c

[Bug ipa/65701] [5 Regression] r221530 makes 187.facerec drop with -Ofast -flto on bdver2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |6.0
            Summary|[5/6 Regression] r221530    |[5 Regression] r221530
                   |makes 187.facerec drop with |makes 187.facerec drop with
                   |-Ofast -flto on bdver2      |-Ofast -flto on bdver2

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
Facerec is back on the tester.

[Bug ipa/65701] [5 Regression] r221530 makes 187.facerec drop with -Ofast -flto on bdver2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.