On Mon, 2007-04-23 at 19:26 +0100, Dave Korn wrote:
> Has any of the Acovea research demonstrated whether there actually is any
> such thing as a "good default set of flags in all cases"? If the results
> obtained diverge significantly according to the nature/coding
> style/architecture/other u
On Mon, 2007-04-23 at 14:06 -0400, Diego Novillo wrote:
> > So, I think there's a middle ground between "exactly the same passes on
> > all targets" and "use Acovea for every CPU to pick what -O2 means".
> > Using Acovea to reveal some of the suprising, but beneficial results,
> > seems like a fin
On 4/23/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote on 04/23/07 14:40:
> Any references?
Yes, at the last HiPEAC conference Grigori Fursin presented their
interactive compilation interface, which could be used for this.
http://gcc-ici.sourceforge.net/
That work is pa
On 23 Apr 2007, at 20:43, Diego Novillo wrote:
[EMAIL PROTECTED] wrote on 04/23/07 14:37:
Currently, the -On flags set/unset 60 flags, which yields 2^60 conbinations.
If you also kind the passes not controlled by a flag, but decided upon
depending on the optimization level, that adds another, vi
On Mon, 2007-04-23 at 10:56 -0700, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
> > On Mon, 23 Apr 2007, Mark Mitchell wrote:
> >
> >> I'm certainly not trying to suggest that we run SPEC on every
> >> architecture, and then make -O2 be the set of optimization options that
> >> happens to do best
[EMAIL PROTECTED] wrote on 04/23/07 14:40:
> Any references?
Yes, at the last HiPEAC conference Grigori Fursin presented their
interactive compilation interface, which could be used for this.
http://gcc-ici.sourceforge.net/
Ben Elliston had also experimented with a framework to allow GCC to
chan
[EMAIL PROTECTED] wrote on 04/23/07 14:37:
> Currently, the -On flags set/unset 60 flags, which yields 2^60 conbinations.
> If you also kind the passes not controlled by a flag, but decided upon
> depending on the optimization level, that adds another, virtual flag
> (i.e. using -O1, -O2, -O3
Citeren Diego Novillo <[EMAIL PROTECTED]>:
Dave Korn wrote on 04/23/07 14:26:
Has any of the Acovea research demonstrated whether there actually is any
such thing as a "good default set of flags in all cases"? If the results
Not Acovea itself. The research I'm talking about involves a co
Citeren Dave Korn <[EMAIL PROTECTED]>:
On 23 April 2007 19:07, Diego Novillo wrote:
Mark Mitchell wrote on 04/23/07 13:56:
So, I think there's a middle ground between "exactly the same passes on
all targets" and "use Acovea for every CPU to pick what -O2 means".
Using Acovea to reveal some o
Dave Korn wrote on 04/23/07 14:26:
> Has any of the Acovea research demonstrated whether there actually is any
> such thing as a "good default set of flags in all cases"? If the results
Not Acovea itself. The research I'm talking about involves a compiler
whose pipeline can be modified and re
Citeren Diego Novillo <[EMAIL PROTECTED]>:
Mark Mitchell wrote on 04/23/07 13:56:
So, I think there's a middle ground between "exactly the same passes on
all targets" and "use Acovea for every CPU to pick what -O2 means".
Using Acovea to reveal some of the suprising, but beneficial results,
se
On 23 April 2007 19:07, Diego Novillo wrote:
> Mark Mitchell wrote on 04/23/07 13:56:
>
>> So, I think there's a middle ground between "exactly the same passes on
>> all targets" and "use Acovea for every CPU to pick what -O2 means".
>> Using Acovea to reveal some of the suprising, but beneficial
Citeren "Kaveh R. GHAZI" <[EMAIL PROTECTED]>:
On Mon, 23 Apr 2007, Mark Mitchell wrote:
I'm certainly not trying to suggest that we run SPEC on every
architecture, and then make -O2 be the set of optimization options that
happens to do best there, however bizarre.
Why not? Is your objection
Mark Mitchell wrote on 04/23/07 13:56:
> So, I think there's a middle ground between "exactly the same passes on
> all targets" and "use Acovea for every CPU to pick what -O2 means".
> Using Acovea to reveal some of the suprising, but beneficial results,
> seems like a fine idea, though.
I'm hopi
Kaveh R. GHAZI wrote:
> On Mon, 23 Apr 2007, Mark Mitchell wrote:
>
>> I'm certainly not trying to suggest that we run SPEC on every
>> architecture, and then make -O2 be the set of optimization options that
>> happens to do best there, however bizarre.
>
> Why not? Is your objection because SPE
On Mon, 23 Apr 2007, Mark Mitchell wrote:
> > I'm certainly not trying to suggest that we run SPEC on every
> > architecture, and then make -O2 be the set of optimization options that
> > happens to do best there, however bizarre.
On Mon, Apr 23, 2007 at 01:21:20PM -0400, Kaveh R. GHAZI wrote:
>
On Mon, 23 Apr 2007, Mark Mitchell wrote:
> I'm certainly not trying to suggest that we run SPEC on every
> architecture, and then make -O2 be the set of optimization options that
> happens to do best there, however bizarre.
Why not? Is your objection because SPEC doesn't reflect real-world apps
On Sun, Apr 22, 2007 at 04:39:23PM -0700, Joe Buck wrote:
>
> On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
> > > At work we use -O3 since it gives 5% performance gain against -O2.
> > > profile-feedback has many flags and there is no overview of it in the
> > > doc IIRC. Who will use
Richard Earnshaw wrote:
> I think it would be nicer if this could be done in a MI way by examining
> certain target properties. For example, the generic framework might say
> something like: 'if there's more than N gp registers, enable opt_foo at
> -O2 or above'.
Yes, I agree; wherever that tech
> (In fact, there's nothing inherent in even using the same algorithms on
> all processors; I can well imagine that the best register allocation
> algorithms for x86 and Itanium might be entirely different. I'm in no
> way trying to encourage an entire set of per-achitecture optimization
> passes;
On Sun, 2007-04-22 at 17:32 -0700, Mark Mitchell wrote:
> Steve Ellcey wrote:
> >> It came up in a few side conversations. As I understand it, RMS has
> >> decreed that the -On optimizations shall be architecture independent.
> >> That said, there are "generic" optimizations which really only appl
Steve Ellcey wrote:
>> It came up in a few side conversations. As I understand it, RMS has
>> decreed that the -On optimizations shall be architecture independent.
>> That said, there are "generic" optimizations which really only apply
>> to a single architecture, so there is some precedent for be
On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
> > At work we use -O3 since it gives 5% performance gain against -O2.
> > profile-feedback has many flags and there is no overview of it in the
> > doc IIRC. Who will use it except GCC developpers? Who knows about your
> > advice?
On Sun
On Sun, 2007-04-22 at 15:22 +0200, Jan Hubicka wrote:
> > At work we use -O3 since it gives 5% performance gain against -O2.
> > profile-feedback has many flags and there is no overview of it in the
> > doc IIRC. Who will use it except GCC developpers? Who knows about your
> > advice?
>
> Well, th
> On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
> > On 4/22/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > > > > but also does not make anyone actually use the options. Nobody reads
> > > > > the documention. Of course, this is a bit overstatement, but with a
> > > > > few excepti
Hello,
> On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
> > On 4/22/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > > > > but also does not make anyone actually use the options. Nobody reads
> > > > > the documention. Of course, this is a bit overstatement, but with a
> > > > > few
On 4/22/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
> On 4/22/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > > > but also does not make anyone actually use the options. Nobody reads
> > > > the documention. Of course, this is a bit
On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
> On 4/22/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > > > but also does not make anyone actually use the options. Nobody reads
> > > > the documention. Of course, this is a bit overstatement, but with a
> > > > few exceptions, peopl
On 4/22/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > but also does not make anyone actually use the options. Nobody reads
> > the documention. Of course, this is a bit overstatement, but with a
> > few exceptions, people in general do not enable non-default flags.
>
> I don't think this is
> > but also does not make anyone actually use the options. Nobody reads
> > the documention. Of course, this is a bit overstatement, but with a
> > few exceptions, people in general do not enable non-default flags.
>
> I don't think this is fair.
> Most people don't read the docs because they d
> > Look from what we're starting:
> >
> > <<
> > @item -funroll-loops
> > @opindex funroll-loops
> > Unroll loops whose number of iterations can be determined at compile
> > time or upon entry to the loop. @option{-funroll-loops} implies
> > @option{-frerun-cse-after-loop}. This option makes co
> Look from what we're starting:
>
> <<
> @item -funroll-loops
> @opindex funroll-loops
> Unroll loops whose number of iterations can be determined at compile
> time or upon entry to the loop. @option{-funroll-loops} implies
> @option{-frerun-cse-after-loop}. This option makes code larger,
> and
On Apr 21, 2007, at 3:12 AM, Robert Dewar wrote:
So, Mike, my question is, assuming we cannot remove the rule what
do you want to do
I think in the end, each situation is different and we have to find
the best solution for each situation. So, in that siprit, let's open
a discussion for th
On Fri, 2007-04-20 at 19:28 -0400, Robert Dewar wrote:
> Steve Ellcey wrote:
>
> > This seems unfortunate. I was hoping I might be able to turn on loop
> > unrolling for IA64 at -O2 to improve performance. I have only started
> > looking into this idea but it seems to help performance quite a bi
Mike Stump wrote:
On Apr 20, 2007, at 6:42 PM, Robert Dewar wrote:
One possibility would be to have a -Om switch (or whatever) that
says "do all optimizations for this machine that help".
Ick, gross. No.
Well OK, Ick, but below you recommend removingf the overly
pedantic rule. I agree with
On Apr 20, 2007, at 6:42 PM, Robert Dewar wrote:
One possibility would be to have a -Om switch (or whatever) that
says "do all optimizations for this machine that help".
Ick, gross. No.
I must say the rule about all optimizations being the same on
all machines seems odd to me
I'd look at i
Robert Dewar wrote on 04/20/07 21:42:
> One possibility would be to have a -Om switch (or whatever) that
> says "do all optimizations for this machine that help".
I think this is a good compromise. I personally don't think we should
limit ourselves to doing the exact same optimizations across al
H. J. Lu wrote on 04/20/07 21:30:
> -fprefetch-loop-arrays shouldn't be on by default since HW prefetch
> usually will have negative performance impact on Intel.
We are talking about one specific architecture where it usually helps: ia64.
Diego Novillo wrote:
H. J. Lu wrote on 04/20/07 21:30:
-fprefetch-loop-arrays shouldn't be on by default since HW prefetch
usually will have negative performance impact on Intel.
We are talking about one specific architecture where it usually helps: ia64.
Right, but the follow on discussion
On Sat, Apr 21, 2007 at 02:19:28AM +0200, Zdenek Dvorak wrote:
> Hello,
>
> > Steve Ellcey wrote:
> >
> > >This seems unfortunate. I was hoping I might be able to turn on loop
> > >unrolling for IA64 at -O2 to improve performance. I have only started
> > >looking into this idea but it seems to
Zdenek Dvorak wrote:
Hello,
Steve Ellcey wrote:
This seems unfortunate. I was hoping I might be able to turn on loop
unrolling for IA64 at -O2 to improve performance. I have only started
looking into this idea but it seems to help performance quite a bit,
though it is also increasing size q
Hello,
> Steve Ellcey wrote:
>
> >This seems unfortunate. I was hoping I might be able to turn on loop
> >unrolling for IA64 at -O2 to improve performance. I have only started
> >looking into this idea but it seems to help performance quite a bit,
> >though it is also increasing size quite a bi
Steve Ellcey wrote:
This seems unfortunate. I was hoping I might be able to turn on loop
unrolling for IA64 at -O2 to improve performance. I have only started
looking into this idea but it seems to help performance quite a bit,
though it is also increasing size quite a bit too so it may need s
> It came up in a few side conversations. As I understand it, RMS has
> decreed that the -On optimizations shall be architecture independent.
> That said, there are "generic" optimizations which really only apply
> to a single architecture, so there is some precedent for bending this
> rule.
>
>
On Fri, Apr 20, 2007 at 12:58:39AM -0700, Ollie Wild wrote:
> >Related to this: have you guys ever considered to making the -On
> >flags dependent on the architecture?
>
> It came up in a few side conversations. As I understand it, RMS has
> decreed that the -On optimizations shall be architectur
Related to this: have you guys ever considered to making the -On
flags dependent on the architecture?
It came up in a few side conversations. As I understand it, RMS has
decreed that the -On optimizations shall be architecture independent.
That said, there are "generic" optimizations which real
On 20 Apr 2007, at 08:30, Ian Lance Taylor wrote:
13) Michael Meissner raised the idea of compiling functions
differently for different processors, choosing the version based
on a runtime decision. This led to some discussion of how this
could be done effectively. In particular if
47 matches
Mail list logo
