Hi,
On Thu, Sep 14, 2017 at 11:55:21AM +0200, Richard Biener wrote:
> On Wed, Sep 13, 2017 at 5:08 PM, Allan Sandfeld Jensen
> wrote:
> > On Mittwoch, 13. September 2017 15:46:09 CEST Jakub Jelinek wrote:
> >> On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
> >> > On its own -O3 d
On Thu, Sep 14, 2017 at 3:08 PM, Markus Trippelsdorf
wrote:
> On 2017.09.14 at 14:48 +0200, Richard Biener wrote:
>> On Thu, Sep 14, 2017 at 12:42 PM, Martin Liška wrote:
>> > On 09/14/2017 12:37 PM, Bin.Cheng wrote:
>> >> On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
>> >> wrote:
>> >>> On T
On 2017.09.14 at 14:48 +0200, Richard Biener wrote:
> On Thu, Sep 14, 2017 at 12:42 PM, Martin Liška wrote:
> > On 09/14/2017 12:37 PM, Bin.Cheng wrote:
> >> On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
> >> wrote:
> >>> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
> On 09/14/2
On Thu, Sep 14, 2017 at 12:42 PM, Martin Liška wrote:
> On 09/14/2017 12:37 PM, Bin.Cheng wrote:
>> On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
>> wrote:
>>> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
> On 2017.09.14 at
On 09/14/2017 12:37 PM, Bin.Cheng wrote:
> On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
> wrote:
>> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
>>> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
> On Wed, Sep 13, 2017
On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
wrote:
> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
>> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
>>> On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras
wrote:
>
On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote:
> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
>> On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
>>> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote:
On 12/09/17 16:57, Wilco Dijkstra wrote:
>
> [...] As a resu
On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
> On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
>> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote:
>>> On 12/09/17 16:57, Wilco Dijkstra wrote:
[...] As a result users are
required to enable several additional optimi
> On 14 Sep 2017, at 3:06 AM, Allan Sandfeld Jensen wrote:
>
> On Dienstag, 12. September 2017 23:27:22 CEST Michael Clark wrote:
>>> On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra wrote:
>>>
>>> Hi all,
>>>
>>> At the GNU Cauldron I was inspired by several interesting talks about
>>> improving G
On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote:
> > On 12/09/17 16:57, Wilco Dijkstra wrote:
> >>
> >> [...] As a result users are
> >> required to enable several additional optimizations by hand to get good
> >> code.
> >> Other comp
On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote:
> On 12/09/17 16:57, Wilco Dijkstra wrote:
>>
>> [...] As a result users are
>> required to enable several additional optimizations by hand to get good
>> code.
>> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM
>>
On Wed, Sep 13, 2017 at 5:08 PM, Allan Sandfeld Jensen
wrote:
> On Mittwoch, 13. September 2017 15:46:09 CEST Jakub Jelinek wrote:
>> On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
>> > On its own -O3 doesn't add much (some loop opts and slightly more
>> > aggressive inlining/unro
On September 13, 2017 6:24:21 PM GMT+02:00, Jan Hubicka wrote:
>> >I don't see static profile prediction to be very useful here to find
>> >"really
>> >hot code" - neither in current implementation or future. The problem
>of
>> >-O2 is that we kind of know that only 10% of code somewhere matters
>
> >I don't see static profile prediction to be very useful here to find
> >"really
> >hot code" - neither in current implementation or future. The problem of
> >-O2 is that we kind of know that only 10% of code somewhere matters for
> >performance but we have no way to reliably identify it.
>
> It
On September 13, 2017 5:35:11 PM GMT+02:00, Jan Hubicka wrote:
>> On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek
>wrote:
>> > On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
>> >> On its own -O3 doesn't add much (some loop opts and slightly more
>> >> aggressive inlining/unrolling
On 12/09/17 16:57, Wilco Dijkstra wrote:
[...] As a result users are
required to enable several additional optimizations by hand to get good code.
Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was
mentioned repeatedly) which GCC could/should do as well.
[...]
I'd welco
> On Wed, Sep 13, 2017 at 3:21 AM, Michael Clark wrote:
> >
> >> On 13 Sep 2017, at 1:15 PM, Michael Clark wrote:
> >>
> >> - https://rv8.io/bench#optimisation
> >> - https://rv8.io/bench#executable-file-sizes
> >>
> >> -O2 is 98% perf of -O3 on x86-64
> >> -Os is 81% perf of -O3 on x86-64
> >>
>
> On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek wrote:
> > On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
> >> On its own -O3 doesn't add much (some loop opts and slightly more
> >> aggressive inlining/unrolling), so whatever it does we
> >> should consider doing at -O2 eventuall
On Mittwoch, 13. September 2017 15:46:09 CEST Jakub Jelinek wrote:
> On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
> > On its own -O3 doesn't add much (some loop opts and slightly more
> > aggressive inlining/unrolling), so whatever it does we
> > should consider doing at -O2 even
On Dienstag, 12. September 2017 23:27:22 CEST Michael Clark wrote:
> > On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra wrote:
> >
> > Hi all,
> >
> > At the GNU Cauldron I was inspired by several interesting talks about
> > improving GCC in various ways. While GCC has many great optimizations, a
> >
On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek wrote:
> On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
>> On its own -O3 doesn't add much (some loop opts and slightly more
>> aggressive inlining/unrolling), so whatever it does we
>> should consider doing at -O2 eventually.
>
> Wel
On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
> On its own -O3 doesn't add much (some loop opts and slightly more
> aggressive inlining/unrolling), so whatever it does we
> should consider doing at -O2 eventually.
Well, -O3 adds vectorization, which we don't enable at -O2 by defa
On Wed, Sep 13, 2017 at 9:43 AM, Janne Blomqvist
wrote:
> On Tue, Sep 12, 2017 at 4:57 PM, Wilco Dijkstra
> wrote:
>> These are just a few ideas to start. What do people think? I'd welcome
>> discussion
>> and other proposals for similar improvements.
>
> What about the default behavior if no o
On Wed, Sep 13, 2017 at 3:21 AM, Michael Clark wrote:
>
>> On 13 Sep 2017, at 1:15 PM, Michael Clark wrote:
>>
>> - https://rv8.io/bench#optimisation
>> - https://rv8.io/bench#executable-file-sizes
>>
>> -O2 is 98% perf of -O3 on x86-64
>> -Os is 81% perf of -O3 on x86-64
>>
>> -O2 saves 5% space
On Tue, Sep 12, 2017 at 4:57 PM, Wilco Dijkstra wrote:
> Hi all,
>
> At the GNU Cauldron I was inspired by several interesting talks about
> improving
> GCC in various ways. While GCC has many great optimizations, a common theme is
> that its default settings are rather conservative. As a result
> * Make -fomit-frame-pointer the default - various targets already do this at
> higher optimization levels, but this could easily be done for all targets.
> Frame pointers haven't been needed for debugging for decades, however if
> there
> are still good reasons to keep it enabled with -O0
> On 13 Sep 2017, at 1:15 PM, Michael Clark wrote:
>
> - https://rv8.io/bench#optimisation
> - https://rv8.io/bench#executable-file-sizes
>
> -O2 is 98% perf of -O3 on x86-64
> -Os is 81% perf of -O3 on x86-64
>
> -O2 saves 5% space on -O3 on x86-64
> -Os saves 8% space on -Os on x86-64
>
> 1
> On 13 Sep 2017, at 12:47 PM, Segher Boessenkool
> wrote:
>
> On Wed, Sep 13, 2017 at 09:27:22AM +1200, Michael Clark wrote:
>>> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was
>>> mentioned repeatedly) which GCC could/should do as well.
>>
>> There are some nuanc
On Wed, Sep 13, 2017 at 09:27:22AM +1200, Michael Clark wrote:
> > Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was
> > mentioned repeatedly) which GCC could/should do as well.
>
> There are some nuances to -O2. Please consider -O2 users who wish use it like
> Clang/LL
> On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra wrote:
>
> Hi all,
>
> At the GNU Cauldron I was inspired by several interesting talks about
> improving
> GCC in various ways. While GCC has many great optimizations, a common theme is
> that its default settings are rather conservative. As a resul
On Tue, 12 Sep 2017, Alexander Monakov wrote:
> > * Make -fno-trapping-math the default - another obvious one. From the docs:
> > "Compile code assuming that floating-point operations cannot generate
> >user-visible traps."
> > There isn't a lot of code that actually uses user-visible tra
On Tue, 12 Sep 2017, Wilco Dijkstra wrote:
> * Make -fno-math-errno the default - this mostly affects the code generated
> for
> sqrt, which should be treated just like floating point division and not set
> errno by default (unless you explicitly select C89 mode).
(note that this can be selec
On Tue, 12 Sep 2017, Wilco Dijkstra wrote:
> * Make -fno-math-errno the default - this mostly affects the code generated
> for
> sqrt, which should be treated just like floating point division and not set
> errno by default (unless you explicitly select C89 mode).
>
> * Make -fno-trapping-ma
On 09/12/2017 05:32 PM, Andrew Pinski wrote:
> .On Tue, Sep 12, 2017 at 8:29 AM, Theodore Papadopoulo
> wrote:
>> Another one that might be interesting is -funsafe-loop-optimizations.
>> In most cases people write loops assuming simple finite loops (no
>> overflow). Crippling optimization for the
.On Tue, Sep 12, 2017 at 8:29 AM, Theodore Papadopoulo
wrote:
> Another one that might be interesting is -funsafe-loop-optimizations.
> In most cases people write loops assuming simple finite loops (no
> overflow). Crippling optimization for the small amount of people (system
> programmers ?) tha
On Tue, 12 Sep 2017, Wilco Dijkstra wrote:
> * Make -fno-trapping-math the default - another obvious one. From the docs:
> "Compile code assuming that floating-point operations cannot generate
>user-visible traps."
> There isn't a lot of code that actually uses user-visible traps (if any
Another one that might be interesting is -funsafe-loop-optimizations.
In most cases people write loops assuming simple finite loops (no
overflow). Crippling optimization for the small amount of people (system
programmers ?) that use such strange loops seems counterproductive. It
would be best if su
Hi all,
At the GNU Cauldron I was inspired by several interesting talks about improving
GCC in various ways. While GCC has many great optimizations, a common theme is
that its default settings are rather conservative. As a result users are
required to enable several additional optimizations by ha
38 matches
Mail list logo
