GCC missing -flto optimizations? SPEC lbm benchmark

GCC missing -flto optimizations? SPEC lbm benchmark

[Steve Ellcey]

I have a question about SPEC CPU 2017 and what GCC can and cannot do
with -flto.  As part of some SPEC analysis I am doing I found that with
-Ofast, ICC and GCC were not that far apart (especially spec int rate,
spec fp rate was a slightly larger difference).

But when I added -ipo to the ICC command and -flto to the GCC command,
the difference got larger.  In particular the 519.lbm_r was more than
twice as fast with ICC and -ipo, but -flto did not help GCC at all.

There are other tests that also show this type of improvement with -ipo
like 538.imagick_r, 544.nab_r, 525.x264_r, 531.deepsjeng_r, and
548.exchange2_r, but none are as dramatic as 519.lbm_r.  Anyone have
any idea on what ICC is doing that GCC is missing?  Is GCC just not
agressive enough with its inlining?

Steve Ellcey
sellcey@marvell.com

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Bin.Cheng]

On Fri, Feb 15, 2019 at 3:30 AM Steve Ellcey <sellcey@marvell.com> wrote:
>
> I have a question about SPEC CPU 2017 and what GCC can and cannot do
> with -flto.  As part of some SPEC analysis I am doing I found that with
> -Ofast, ICC and GCC were not that far apart (especially spec int rate,
> spec fp rate was a slightly larger difference).
>
> But when I added -ipo to the ICC command and -flto to the GCC command,
> the difference got larger.  In particular the 519.lbm_r was more than
> twice as fast with ICC and -ipo, but -flto did not help GCC at all.
>
> There are other tests that also show this type of improvement with -ipo
> like 538.imagick_r, 544.nab_r, 525.x264_r, 531.deepsjeng_r, and
> 548.exchange2_r, but none are as dramatic as 519.lbm_r.  Anyone have
> any idea on what ICC is doing that GCC is missing?  Is GCC just not
> agressive enough with its inlining?

IIRC Jun did some investigation before? CCing.

Thanks,
bin
>
> Steve Ellcey
> sellcey@marvell.com

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Jun Ma]

Bin.Cheng <amker.cheng@gmail.com> 于2019年2月15日周五 下午5:12写道：

> On Fri, Feb 15, 2019 at 3:30 AM Steve Ellcey <sellcey@marvell.com> wrote:
> >
> > I have a question about SPEC CPU 2017 and what GCC can and cannot do
> > with -flto.  As part of some SPEC analysis I am doing I found that with
> > -Ofast, ICC and GCC were not that far apart (especially spec int rate,
> > spec fp rate was a slightly larger difference).
> >
> > But when I added -ipo to the ICC command and -flto to the GCC command,
> > the difference got larger.  In particular the 519.lbm_r was more than
> > twice as fast with ICC and -ipo, but -flto did not help GCC at all.
> >
> > There are other tests that also show this type of improvement with -ipo
> > like 538.imagick_r, 544.nab_r, 525.x264_r, 531.deepsjeng_r, and
> > 548.exchange2_r, but none are as dramatic as 519.lbm_r.  Anyone have
> > any idea on what ICC is doing that GCC is missing?  Is GCC just not
> > agressive enough with its inlining?
>
> IIRC Jun did some investigation before? CCing.
>
> Thanks,
> bin
> >
> > Steve Ellcey
> > sellcey@marvell.com

ICC is doing much more than GCC in ipo, especially memory layout
optimizations. See https://software.intel.com/en-us/node/522667.
ICC is more aggressive in array transposition/structure splitting
/field reordering. However, these optimizations have been removed
from GCC long time ago.
As for case lbm_r, IIRC a loop with memory access which stride is 20 is
most time-consuming.  ICC will optimize the array(maybe structure?)
and vectorize the loop under ipo.

Thanks
Jun

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Hi-Angel]

I never could understand, why field reordering was removed from GCC? I
mean, I know that it's prohibited in C and C++, but, sure, GCC can
detect whether it possibly can influence application behavior, and if
not, just do the reorder.

The veto is important to C/C++ as programming languages, but not to
machine code that is being generated from them. As long as app can't
detect that its fields were reordered through means defined by C/C++,
field reordering by compiler is fine, isn't it?

On Fri, 15 Feb 2019 at 12:49, Jun Ma <majun4950646@gmail.com> wrote:
>
> Bin.Cheng <amker.cheng@gmail.com> 于2019年2月15日周五 下午5:12写道：
>
> > On Fri, Feb 15, 2019 at 3:30 AM Steve Ellcey <sellcey@marvell.com> wrote:
> > >
> > > I have a question about SPEC CPU 2017 and what GCC can and cannot do
> > > with -flto.  As part of some SPEC analysis I am doing I found that with
> > > -Ofast, ICC and GCC were not that far apart (especially spec int rate,
> > > spec fp rate was a slightly larger difference).
> > >
> > > But when I added -ipo to the ICC command and -flto to the GCC command,
> > > the difference got larger.  In particular the 519.lbm_r was more than
> > > twice as fast with ICC and -ipo, but -flto did not help GCC at all.
> > >
> > > There are other tests that also show this type of improvement with -ipo
> > > like 538.imagick_r, 544.nab_r, 525.x264_r, 531.deepsjeng_r, and
> > > 548.exchange2_r, but none are as dramatic as 519.lbm_r.  Anyone have
> > > any idea on what ICC is doing that GCC is missing?  Is GCC just not
> > > agressive enough with its inlining?
> >
> > IIRC Jun did some investigation before? CCing.
> >
> > Thanks,
> > bin
> > >
> > > Steve Ellcey
> > > sellcey@marvell.com
>
> ICC is doing much more than GCC in ipo, especially memory layout
> optimizations. See https://software.intel.com/en-us/node/522667.
> ICC is more aggressive in array transposition/structure splitting
> /field reordering. However, these optimizations have been removed
> from GCC long time ago.
> As for case lbm_r, IIRC a loop with memory access which stride is 20 is
> most time-consuming.  ICC will optimize the array(maybe structure?)
> and vectorize the loop under ipo.
>
> Thanks
> Jun

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Richard Biener]

On February 15, 2019 1:45:10 PM GMT+01:00, Hi-Angel <hiangel999@gmail.com> wrote:
>I never could understand, why field reordering was removed from GCC?

The implementation simply was seriously broken, bitrotten and unmaintained. 

Richard 

 I
>mean, I know that it's prohibited in C and C++, but, sure, GCC can
>detect whether it possibly can influence application behavior, and if
>not, just do the reorder.
>
>The veto is important to C/C++ as programming languages, but not to
>machine code that is being generated from them. As long as app can't
>detect that its fields were reordered through means defined by C/C++,
>field reordering by compiler is fine, isn't it?
>
>On Fri, 15 Feb 2019 at 12:49, Jun Ma <majun4950646@gmail.com> wrote:
>>
>> Bin.Cheng <amker.cheng@gmail.com> 于2019年2月15日周五 下午5:12写道：
>>
>> > On Fri, Feb 15, 2019 at 3:30 AM Steve Ellcey <sellcey@marvell.com>
>wrote:
>> > >
>> > > I have a question about SPEC CPU 2017 and what GCC can and cannot
>do
>> > > with -flto.  As part of some SPEC analysis I am doing I found
>that with
>> > > -Ofast, ICC and GCC were not that far apart (especially spec int
>rate,
>> > > spec fp rate was a slightly larger difference).
>> > >
>> > > But when I added -ipo to the ICC command and -flto to the GCC
>command,
>> > > the difference got larger.  In particular the 519.lbm_r was more
>than
>> > > twice as fast with ICC and -ipo, but -flto did not help GCC at
>all.
>> > >
>> > > There are other tests that also show this type of improvement
>with -ipo
>> > > like 538.imagick_r, 544.nab_r, 525.x264_r, 531.deepsjeng_r, and
>> > > 548.exchange2_r, but none are as dramatic as 519.lbm_r.  Anyone
>have
>> > > any idea on what ICC is doing that GCC is missing?  Is GCC just
>not
>> > > agressive enough with its inlining?
>> >
>> > IIRC Jun did some investigation before? CCing.
>> >
>> > Thanks,
>> > bin
>> > >
>> > > Steve Ellcey
>> > > sellcey@marvell.com
>>
>> ICC is doing much more than GCC in ipo, especially memory layout
>> optimizations. See https://software.intel.com/en-us/node/522667.
>> ICC is more aggressive in array transposition/structure splitting
>> /field reordering. However, these optimizations have been removed
>> from GCC long time ago.
>> As for case lbm_r, IIRC a loop with memory access which stride is 20
>is
>> most time-consuming.  ICC will optimize the array(maybe structure?)
>> and vectorize the loop under ipo.
>>
>> Thanks
>> Jun

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Jakub Jelinek]

On Fri, Feb 15, 2019 at 02:12:27PM +0100, Richard Biener wrote:
> On February 15, 2019 1:45:10 PM GMT+01:00, Hi-Angel <hiangel999@gmail.com> wrote:
> >I never could understand, why field reordering was removed from GCC?
> 
> The implementation simply was seriously broken, bitrotten and unmaintained. 

Which of course doesn't mean somebody else can't submit a new
implementation, as long as it would be properly maintained and would avoid
the issues the old implementation had.  Just it is better not to have it if
it causes lots of wrong-code issues and there is nobody to fix those.

	Jakub

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Ramana Radhakrishnan]

On Fri, Feb 15, 2019 at 1:16 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Fri, Feb 15, 2019 at 02:12:27PM +0100, Richard Biener wrote:
> > On February 15, 2019 1:45:10 PM GMT+01:00, Hi-Angel <hiangel999@gmail.com> wrote:
> > >I never could understand, why field reordering was removed from GCC?
> >
> > The implementation simply was seriously broken, bitrotten and unmaintained.
>
> Which of course doesn't mean somebody else can't submit a new
> implementation, as long as it would be properly maintained and would avoid
> the issues the old implementation had.  Just it is better not to have it if
> it causes lots of wrong-code issues and there is nobody to fix those.

I also remember a cauldron talk in the recent past about this. It was in Prague.
Ah , here's a youtube video of it. :

https://www.youtube.com/watch?v=vhV75sys0Nw



Ramana



>
>         Jakub

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Ian Lance Taylor]

On Fri, Feb 15, 2019 at 4:46 AM Hi-Angel <hiangel999@gmail.com> wrote:
>
> I never could understand, why field reordering was removed from GCC? I
> mean, I know that it's prohibited in C and C++, but, sure, GCC can
> detect whether it possibly can influence application behavior, and if
> not, just do the reorder.
>
> The veto is important to C/C++ as programming languages, but not to
> machine code that is being generated from them. As long as app can't
> detect that its fields were reordered through means defined by C/C++,
> field reordering by compiler is fine, isn't it?

In my opinion field reordering is very hard for the compiler to do
correctly and trivial for a human programmer to do correctly.  So in
practice the best approach is for the compiler, or some other tool, to
say "you should reorder the fields here."  As far as I can see, the
only real reason to implement field reordering in a compiler is for
benchmark cracking, since benchmarks typically don't let you modify
the source code.  It's not a useful optimization in practice other
than for benchmarks.

(Array transformations and struct splitting, on the other hand, can be useful.)

Ian



> On Fri, 15 Feb 2019 at 12:49, Jun Ma <majun4950646@gmail.com> wrote:
> >
> > Bin.Cheng <amker.cheng@gmail.com> 于2019年2月15日周五 下午5:12写道：
> >
> > > On Fri, Feb 15, 2019 at 3:30 AM Steve Ellcey <sellcey@marvell.com> wrote:
> > > >
> > > > I have a question about SPEC CPU 2017 and what GCC can and cannot do
> > > > with -flto.  As part of some SPEC analysis I am doing I found that with
> > > > -Ofast, ICC and GCC were not that far apart (especially spec int rate,
> > > > spec fp rate was a slightly larger difference).
> > > >
> > > > But when I added -ipo to the ICC command and -flto to the GCC command,
> > > > the difference got larger.  In particular the 519.lbm_r was more than
> > > > twice as fast with ICC and -ipo, but -flto did not help GCC at all.
> > > >
> > > > There are other tests that also show this type of improvement with -ipo
> > > > like 538.imagick_r, 544.nab_r, 525.x264_r, 531.deepsjeng_r, and
p> > > > 548.exchange2_r, but none are as dramatic as 519.lbm_r.  Anyone have
> > > > any idea on what ICC is doing that GCC is missing?  Is GCC just not
> > > > agressive enough with its inlining?
> > >
> > > IIRC Jun did some investigation before? CCing.
> > >
> > > Thanks,
> > > bin
> > > >
> > > > Steve Ellcey
> > > > sellcey@marvell.com
> >
> > ICC is doing much more than GCC in ipo, especially memory layout
> > optimizations. See https://software.intel.com/en-us/node/522667.
> > ICC is more aggressive in array transposition/structure splitting
> > /field reordering. However, these optimizations have been removed
> > from GCC long time ago.
> > As for case lbm_r, IIRC a loop with memory access which stride is 20 is
> > most time-consuming.  ICC will optimize the array(maybe structure?)
> > and vectorize the loop under ipo.
> >
> > Thanks
> > Jun

Re: [EXT] Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Steve Ellcey]

On Fri, 2019-02-15 at 17:48 +0800, Jun Ma wrote:
> 
> ICC is doing much more than GCC in ipo, especially memory layout 
> optimizations. See https://software.intel.com/en-us/node/522667.
> ICC is more aggressive in array transposition/structure splitting
> /field reordering. However, these optimizations have been removed
> from GCC long time ago.  
> As for case lbm_r, IIRC a loop with memory access which stride is 20 is 
> most time-consuming.  ICC will optimize the array(maybe structure?) 
> and vectorize the loop under ipo.
>  
> Thanks
> Jun

Interesting.  I tried using '-qno-opt-mem-layout-trans' on ICC
along with '-Ofast -ipo' and that had no affect on the speed.  I also
tried '-no-vec' and that had no affect either.  The only thing that 
slowed down ICC was '-ip-no-inlining' or '-fno-inline'.  I see that
'-Ofast -ipo' resulted in everything (except libc functions) getting
inlined into the main program when using ICC.  GCC did not do that, but
if I forced it to by using the always_inline attribute, GCC could
inline everything into main the way ICC does.  But that did not speed
up the GCC executable.

Steve Ellcey
sellcey@marvell.com

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Joel Sherrill]

On Fri, Feb 15, 2019 at 9:02 AM Ian Lance Taylor <iant@golang.org> wrote:

> On Fri, Feb 15, 2019 at 4:46 AM Hi-Angel <hiangel999@gmail.com> wrote:
> >
> > I never could understand, why field reordering was removed from GCC? I
> > mean, I know that it's prohibited in C and C++, but, sure, GCC can
> > detect whether it possibly can influence application behavior, and if
> > not, just do the reorder.
> >
> > The veto is important to C/C++ as programming languages, but not to
> > machine code that is being generated from them. As long as app can't
> > detect that its fields were reordered through means defined by C/C++,
> > field reordering by compiler is fine, isn't it?
>
> In my opinion field reordering is very hard for the compiler to do
> correctly and trivial for a human programmer to do correctly.  So in
> practice the best approach is for the compiler, or some other tool, to
> say "you should reorder the fields here."  As far as I can see, the
> only real reason to implement field reordering in a compiler is for
> benchmark cracking, since benchmarks typically don't let you modify
> the source code.  It's not a useful optimization in practice other
> than for benchmarks.
>

Hasn't GNAT sorted Ada elements in records (e.g. structures) by size
since near its initial addition to GCC in the mid-90s? This results in the
largest elements up front and minimizes the need for alignment gaps.

I know Ada is traditionally more strongly typed than C/C++, but tf it can
be done for Ada programs reliably, why could it not be reliable in C?

>
> (Array transformations and struct splitting, on the other hand, can be
> useful.)
>

--joel

>
> Ian
>
>
>
> > On Fri, 15 Feb 2019 at 12:49, Jun Ma <majun4950646@gmail.com> wrote:
> > >
> > > Bin.Cheng <amker.cheng@gmail.com> 于2019年2月15日周五 下午5:12写道：
> > >
> > > > On Fri, Feb 15, 2019 at 3:30 AM Steve Ellcey <sellcey@marvell.com>
> wrote:
> > > > >
> > > > > I have a question about SPEC CPU 2017 and what GCC can and cannot
> do
> > > > > with -flto.  As part of some SPEC analysis I am doing I found that
> with
> > > > > -Ofast, ICC and GCC were not that far apart (especially spec int
> rate,
> > > > > spec fp rate was a slightly larger difference).
> > > > >
> > > > > But when I added -ipo to the ICC command and -flto to the GCC
> command,
> > > > > the difference got larger.  In particular the 519.lbm_r was more
> than
> > > > > twice as fast with ICC and -ipo, but -flto did not help GCC at all.
> > > > >
> > > > > There are other tests that also show this type of improvement with
> -ipo
> > > > > like 538.imagick_r, 544.nab_r, 525.x264_r, 531.deepsjeng_r, and
> p> > > > 548.exchange2_r, but none are as dramatic as 519.lbm_r.  Anyone
> have
> > > > > any idea on what ICC is doing that GCC is missing?  Is GCC just not
> > > > > agressive enough with its inlining?
> > > >
> > > > IIRC Jun did some investigation before? CCing.
> > > >
> > > > Thanks,
> > > > bin
> > > > >
> > > > > Steve Ellcey
> > > > > sellcey@marvell.com
> > >
> > > ICC is doing much more than GCC in ipo, especially memory layout
> > > optimizations. See https://software.intel.com/en-us/node/522667.
> > > ICC is more aggressive in array transposition/structure splitting
> > > /field reordering. However, these optimizations have been removed
> > > from GCC long time ago.
> > > As for case lbm_r, IIRC a loop with memory access which stride is 20 is
> > > most time-consuming.  ICC will optimize the array(maybe structure?)
> > > and vectorize the loop under ipo.
> > >
> > > Thanks
> > > Jun
>

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Richard Kenner]

> Hasn't GNAT sorted Ada elements in records (e.g. structures) by size
> since near its initial addition to GCC in the mid-90s? 

No, it wasn't done early on and it was never done in that major a way
now.  Most reordering (possibly all; I'm not sure) is done between
objects of variable and fixed size, not between objects of differing
fixed sizes.

> I know Ada is traditionally more strongly typed than C/C++, but tf it can
> be done for Ada programs reliably, why could it not be reliable in C?

I don't see it as a reliability issue, but one of expectations.  One might
be using a struct to map some hardware layout or records in a file so that
reordering fields could break things.

Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Eric Botcazou]

> Hasn't GNAT sorted Ada elements in records (e.g. structures) by size
> since near its initial addition to GCC in the mid-90s? This results in the
> largest elements up front and minimizes the need for alignment gaps.

No, that's a serious misconception, since one of the features of GNAT is to be 
compatible with C by default as much as possible.  But we started to do some 
reordering recently when the records don't have (direct) equivalents in C.

-- 
Eric Botcazou

Re: [EXT] Re: GCC missing -flto optimizations? SPEC lbm benchmark

[Jun Ma]

Steve Ellcey <sellcey@marvell.com> 于2019年2月16日周六 上午1:53写道：

> On Fri, 2019-02-15 at 17:48 +0800, Jun Ma wrote:
> >
> > ICC is doing much more than GCC in ipo, especially memory layout
> > optimizations. See https://software.intel.com/en-us/node/522667.
> > ICC is more aggressive in array transposition/structure splitting
> > /field reordering. However, these optimizations have been removed
> > from GCC long time ago.
> > As for case lbm_r, IIRC a loop with memory access which stride is 20 is
> > most time-consuming.  ICC will optimize the array(maybe structure?)
> > and vectorize the loop under ipo.
> >
> > Thanks
> > Jun
>
> Interesting.  I tried using '-qno-opt-mem-layout-trans' on ICC
> along with '-Ofast -ipo' and that had no affect on the speed.  I also
> tried '-no-vec' and that had no affect either.  The only thing that
> slowed down ICC was '-ip-no-inlining' or '-fno-inline'.  I see that
> '-Ofast -ipo' resulted in everything (except libc functions) getting
> inlined into the main program when using ICC.  GCC did not do that, but
> if I forced it to by using the always_inline attribute, GCC could
> inline everything into main the way ICC does.  But that did not speed
> up the GCC executable.
>
> Steve Ellcey
> sellcey@marvell.com

 you can use '-qopt-report' to see which optimizations has been applied by
icc.

Thanks
Jun