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 Mon, Apr 23, 2007 at 09:49:04AM -0700, Steve Ellcey wrote:
> Jim Wilson wrote:
>
> > Kenneth Hoste wrote:
> > > I'm not sure what 'tests' mean here... Are test cases being extracted
> > > from the SPEC CPU2006 sources? Or are you refering to the validity tests
> > > of the SPEC framework itself
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
Jim Wilson wrote:
> Kenneth Hoste wrote:
> > I'm not sure what 'tests' mean here... Are test cases being extracted
> > from the SPEC CPU2006 sources? Or are you refering to the validity tests
> > of the SPEC framework itself (to check whether the output generated by
> > some binary conforms with t
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
Ian Lance Taylor wrote:
> We held a GCC mini-summit at Google on Wednesday, April 18. About 40
> people came. This is my very brief summary of what we talked about.
> Corrections and additions very welcome.
Thank you for the summary.
I am disappointed that I wasn't able to attend, as it sounds
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
Kenneth Hoste wrote:
I'm not sure what 'tests' mean here... Are test cases being extracted
from the SPEC CPU2006 sources? Or are you refering to the validity tests
of the SPEC framework itself (to check whether the output generated by
some binary conforms with their reference output)?
The cla
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.
>
>
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>> Alternatively, filtering by regex would work just as well for me.
Dan> It *is* a regex :)
Hmm. I type "cpp|preprocessor" into the text area and I get no
results. I also tried emacs-style: cpp\|preprocessor. What am I
missing?
Tom
On 20 Apr 2007 11:42:57 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
Ian> I proposed automatic e-mail pings, but that wasn't generally
Ian> welcomed.
Bummer. Why?
Dan> If people are okay with this, I have no problem implementing it.
If you're taking feature requests, it would be handy to cano
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
>> If you're taking feature requests, it would be handy to canonize the
>> Area field somehow. I was filtering based on "preprocessor" and then
>> yesterday noticed things filed against "libcpp" and "cpp".
Dave> Heh. Guilty as charged.
So
On 20 April 2007 18:43, Tom Tromey wrote:
> Ian> I proposed automatic e-mail pings, but that wasn't generally
> Ian> welcomed.
>
> Bummer. Why?
>
> Dan> If people are okay with this, I have no problem implementing it.
>
> If you're taking feature requests, it would be handy to canonize the
> A
Ian> I proposed automatic e-mail pings, but that wasn't generally
Ian> welcomed.
Bummer. Why?
Dan> If people are okay with this, I have no problem implementing it.
If you're taking feature requests, it would be handy to canonize the
Area field somehow. I was filtering based on "preprocessor" a
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
> > 10) Eric Christopher reported that Tom Tromey (who was not present)
> > had suggested a new mascot for gcc: a unicorn with rainbows. This
> >was met with general approval, and Eric suggested that everybody
> >e-mail Tom with their comments. I personally would like to see
> >
Steven Bosscher wrote:
On 4/20/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
> Yes, you have complained that you believe the data structure of DF is
> too fat. I guess that is a valid complaint. I don't see the "rtl info
> duplication" though. You've only complained about the current data
On 4/20/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
> Yes, you have complained that you believe the data structure of DF is
> too fat. I guess that is a valid complaint. I don't see the "rtl info
> duplication" though. You've only complained about the current data
> structures, but I have
Steven Bosscher wrote:
On 4/20/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
Did not I write several times that the data structure of DF is too fat
(because rtl info duplication) and that is probably the problem?
Yes, you have complained that you believe the data structure of DF is
too
On 4/20/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
Did not I write several times that the data structure of DF is too fat
(because rtl info duplication) and that is probably the problem?
Yes, you have complained that you believe the data structure of DF is
too fat. I guess that is a val
Vladimir N. Makarov wrote:
And I am disagree that it is within compilation time guidelines set
by SC. Ken fixed a big compilation time degradation a few days ago
and preliminary what I see now (comparison with the last merge point)
is
x86_64
SPECInt2000 5.7%
SPECFp200 8.7%
ppc64
SPECInt200
Steven Bosscher wrote:
On 4/20/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
I am afraid that merging it earlier stops progress on the df
infrastructurey (e.g. Ken will work only on LTO)
There's nothing holding you, and many others, back from helping out,
other than that the work is on
Ian Lance Taylor wrote:
4) A discussion of dataflow. Ken Zadeck described the current state
of dataflow branch. It seems stable, and just about within the
compilation time guidelines set by the SC. He will do more testing
and retesting this weekend, and hopes to commit it to mainline
On 4/20/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
I am afraid that merging it earlier stops progress on the df
infrastructurey (e.g. Ken will work only on LTO)
There's nothing holding you, and many others, back from helping out,
other than that the work is on a branch. By merging, the
> 10) Eric Christopher reported that Tom Tromey (who was not present)
> had suggested a new mascot for gcc: a unicorn with rainbows. This
>was met with general approval, and Eric suggested that everybody
>e-mail Tom with their comments. I personally would like to see
>the drawing
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
On 20 Apr 2007, at 08:30, Ian Lance Taylor wrote:
11) H.J. Lu discussed SPEC CPU 2006. He reported that a couple of the
tests do not run successfully, and it appears to be due to bugs in
the tests which cause gcc to compile them in unexpected ways. He
has been reporting the proble
67 matches
Mail list logo
