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 fine idea,
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
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 part
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 apply
to a
(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;
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
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 their
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 it except
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 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:
Why
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
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 hoping to
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
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 results,
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,
seems
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
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 of the
[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 or
[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
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 there,
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,
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 (to check
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 may or
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 don't
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
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 exceptions, people
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, this is why
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, Apr
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 bending
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
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
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
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 bit,
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
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.
The goal of the mini-summit was just to let gcc developers meet face
to face and talk. There was no goal of actually
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
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
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
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.
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
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
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
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:
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 not
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
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
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 architecture
We discussed the patch tracker. None of the active maintainers who
were there appear to use it very much or at all.
This is because it does not enable them to easily review patches, only
to see which they have missed ;)
I proposed
automatic e-mail pings, but that wasn't generally
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 and
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
Area field
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.
Sorry, wasn't trying to
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 canonize
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 bit too so
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
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
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.
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 all
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 it
A reminder. This will happen next week.
Several gcc developers are presenting at the Gelato conference in San
Jose this April. Google is inviting them and all other interested
parties to a gcc mini-summit at Google's Mountain View campus. The
mini-summit will be on Wednesday, April 18
Several gcc developers are presenting at the Gelato conference in San
Jose this April. Google is inviting them and all other interested
parties to a gcc mini-summit at Google's Mountain View campus. The
mini-summit will be on Wednesday, April 18, in Google building 40,
from 10am to 5pm
60 matches
Mail list logo
