* Proposal: -O4 -> strict-aliasing
@ 1999-10-26 5:21 nbecker
1999-10-26 8:50 ` Mark Mitchell
1999-10-31 23:35 ` nbecker
0 siblings, 2 replies; 24+ messages in thread
From: nbecker @ 1999-10-26 5:21 UTC (permalink / raw)
To: gcc
Subject says it all.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-26 5:21 Proposal: -O4 -> strict-aliasing nbecker
@ 1999-10-26 8:50 ` Mark Mitchell
1999-10-27 0:18 ` Andris Pavenis
` (2 more replies)
1999-10-31 23:35 ` nbecker
1 sibling, 3 replies; 24+ messages in thread
From: Mark Mitchell @ 1999-10-26 8:50 UTC (permalink / raw)
To: nbecker; +Cc: gcc
>>>>> "nbecker" == nbecker <nbecker@fred.net> writes:
nbecker> Subject says it all.
I'm not sure this is the right thing. We certainly have customers who
want -O2 and -fstrict-aliasing, but specifically don't want function
that aren't marked inline to be inlined. (And -O3 has some serious
compile-time memory usage implications.) Basically, I don't think
this optimization falls into a total ordering above
-finline-functions.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-26 8:50 ` Mark Mitchell
@ 1999-10-27 0:18 ` Andris Pavenis
1999-10-29 18:22 ` Gerald Pfeifer
1999-10-31 23:35 ` Andris Pavenis
1999-10-28 5:33 ` nbecker
1999-10-31 23:35 ` Mark Mitchell
2 siblings, 2 replies; 24+ messages in thread
From: Andris Pavenis @ 1999-10-27 0:18 UTC (permalink / raw)
To: Mark Mitchell, nbecker; +Cc: gcc
On Tue, 26 Oct 1999, Mark Mitchell wrote:
> >>>>> "nbecker" == nbecker <nbecker@fred.net> writes:
>
> nbecker> Subject says it all.
>
> I'm not sure this is the right thing. We certainly have customers who
> want -O2 and -fstrict-aliasing, but specifically don't want function
> that aren't marked inline to be inlined. (And -O3 has some serious
> compile-time memory usage implications.) Basically, I don't think
> this optimization falls into a total ordering above
> -finline-functions.
>
Perhaps one who needs -fstrict-aliasing with 2.95.2 could simply modify
specs by adding '%(!no-strict-aliasing: -fstrict-aliasing)' to cc1_spec
(or one can do the oposite with gcc-2.95.1 and gcc-2.95 to disable strict
aliasing). So the default can be simply changed.
Maybe such hack should be mentioned in FAQ.
Andris
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-26 8:50 ` Mark Mitchell
1999-10-27 0:18 ` Andris Pavenis
@ 1999-10-28 5:33 ` nbecker
1999-10-28 6:21 ` Richard Earnshaw
` (2 more replies)
1999-10-31 23:35 ` Mark Mitchell
2 siblings, 3 replies; 24+ messages in thread
From: nbecker @ 1999-10-28 5:33 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>>>>> "nbecker" == nbecker <nbecker@fred.net> writes:
nbecker> Subject says it all.
Mark> I'm not sure this is the right thing. We certainly have customers who
Mark> want -O2 and -fstrict-aliasing, but specifically don't want function
Mark> that aren't marked inline to be inlined. (And -O3 has some serious
Mark> compile-time memory usage implications.) Basically, I don't think
Mark> this optimization falls into a total ordering above
Mark> -finline-functions.
I understand your point. There is almost never a perfect mapping from
a multidimensional space to a one dimensional space. But I think the
proposal is a good one.
0) no opt
1) quick/simple opt
2) extensive/expensive opt
3) opt that may increase code size
4) potentially dangerous opt
Sure, it won't suit every need, but I think it's sensible and will be
useful to the vast majority of users.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-28 5:33 ` nbecker
@ 1999-10-28 6:21 ` Richard Earnshaw
1999-10-31 23:35 ` Richard Earnshaw
1999-10-28 8:14 ` Mark Mitchell
1999-10-31 23:35 ` nbecker
2 siblings, 1 reply; 24+ messages in thread
From: Richard Earnshaw @ 1999-10-28 6:21 UTC (permalink / raw)
To: nbecker; +Cc: richard.earnshaw
nbecker@fred.net said:
> 0) no opt
> 1) quick/simple opt
> 2) extensive/expensive opt
> 3) opt that may increase code size
> 4) potentially dangerous opt
There is nothing potentially dangerous about -mstrict-aliasing if your
code is written according to the rules for ANSI C.
There are many other optimizations in the compiler that will break code
that doesn't meet the standard; I don't see why we should make an
exception for this one.
R.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-28 5:33 ` nbecker
1999-10-28 6:21 ` Richard Earnshaw
@ 1999-10-28 8:14 ` Mark Mitchell
1999-10-31 23:35 ` Mark Mitchell
1999-10-31 23:35 ` nbecker
2 siblings, 1 reply; 24+ messages in thread
From: Mark Mitchell @ 1999-10-28 8:14 UTC (permalink / raw)
To: nbecker; +Cc: gcc
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
4) potentially dangerous opt
But I don't think we should encourage people to think of
-fstrict-aliasing this way. As we've discussed, lots of previous
optimizations broke code that "always worked" before.
It's OK that we've disabled -fstrict-aliasing by default; hopefully,
at some point, it will be culturally acceptable to turn it back on.
But, when we do, it should be at O2, not at something beyond O3. It's
an:
2) extensive/expensive opt
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-27 0:18 ` Andris Pavenis
@ 1999-10-29 18:22 ` Gerald Pfeifer
1999-10-30 1:37 ` Andris Pavenis
` (2 more replies)
1999-10-31 23:35 ` Andris Pavenis
1 sibling, 3 replies; 24+ messages in thread
From: Gerald Pfeifer @ 1999-10-29 18:22 UTC (permalink / raw)
To: Andris Pavenis; +Cc: Mark Mitchell, nbecker, gcc
On Wed, 27 Oct 1999, Andris Pavenis wrote:
> Perhaps one who needs -fstrict-aliasing with 2.95.2 could simply modify
> specs by adding '%(!no-strict-aliasing: -fstrict-aliasing)' to cc1_spec
> (or one can do the oposite with gcc-2.95.1 and gcc-2.95 to disable strict
> aliasing). So the default can be simply changed.
>
> Maybe such hack should be mentioned in FAQ.
Personally I don't think we should add that to the FAQ, but if others feel
differently, please let me know, I don't have any strong preference.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-29 18:22 ` Gerald Pfeifer
@ 1999-10-30 1:37 ` Andris Pavenis
1999-10-31 23:35 ` Andris Pavenis
1999-10-31 17:41 ` Alexandre Oliva
1999-10-31 23:35 ` Gerald Pfeifer
2 siblings, 1 reply; 24+ messages in thread
From: Andris Pavenis @ 1999-10-30 1:37 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: Mark Mitchell, nbecker, gcc
On Sat, 30 Oct 1999, Gerald Pfeifer wrote:
> On Wed, 27 Oct 1999, Andris Pavenis wrote:
> > Perhaps one who needs -fstrict-aliasing with 2.95.2 could simply modify
> > specs by adding '%(!no-strict-aliasing: -fstrict-aliasing)' to cc1_spec
Sorry I had typo here. It should be:
%{!no-strict-aliasing: -fstrict-aliasing}
> > (or one can do the oposite with gcc-2.95.1 and gcc-2.95 to disable strict
> > aliasing). So the default can be simply changed.
> >
> > Maybe such hack should be mentioned in FAQ.
>
> Personally I don't think we should add that to the FAQ, but if others feel
> differently, please let me know, I don't have any strong preference.
>
> Gerald
> --
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-29 18:22 ` Gerald Pfeifer
1999-10-30 1:37 ` Andris Pavenis
@ 1999-10-31 17:41 ` Alexandre Oliva
1999-10-31 23:35 ` Alexandre Oliva
1999-10-31 23:35 ` Gerald Pfeifer
2 siblings, 1 reply; 24+ messages in thread
From: Alexandre Oliva @ 1999-10-31 17:41 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: Andris Pavenis, Mark Mitchell, nbecker, gcc
On Oct 29, 1999, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:
> On Wed, 27 Oct 1999, Andris Pavenis wrote:
>> Perhaps one who needs -fstrict-aliasing with 2.95.2 could simply modify
>> specs by adding '%(!no-strict-aliasing: -fstrict-aliasing)' to cc1_spec
>> (or one can do the oposite with gcc-2.95.1 and gcc-2.95 to disable strict
>> aliasing). So the default can be simply changed.
>>
>> Maybe such hack should be mentioned in FAQ.
> Personally I don't think we should add that to the FAQ, but if others feel
> differently, please let me know, I don't have any strong preference.
Someone wrote before that we shouldn't teach people to modify their
spec files, as this generally leads to irreproducible bug reports,
because of the hidden arguments passed to the compiler.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-28 8:14 ` Mark Mitchell
@ 1999-10-31 23:35 ` Mark Mitchell
0 siblings, 0 replies; 24+ messages in thread
From: Mark Mitchell @ 1999-10-31 23:35 UTC (permalink / raw)
To: nbecker; +Cc: gcc
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
4) potentially dangerous opt
But I don't think we should encourage people to think of
-fstrict-aliasing this way. As we've discussed, lots of previous
optimizations broke code that "always worked" before.
It's OK that we've disabled -fstrict-aliasing by default; hopefully,
at some point, it will be culturally acceptable to turn it back on.
But, when we do, it should be at O2, not at something beyond O3. It's
an:
2) extensive/expensive opt
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-28 6:21 ` Richard Earnshaw
@ 1999-10-31 23:35 ` Richard Earnshaw
0 siblings, 0 replies; 24+ messages in thread
From: Richard Earnshaw @ 1999-10-31 23:35 UTC (permalink / raw)
To: nbecker; +Cc: richard.earnshaw
nbecker@fred.net said:
> 0) no opt
> 1) quick/simple opt
> 2) extensive/expensive opt
> 3) opt that may increase code size
> 4) potentially dangerous opt
There is nothing potentially dangerous about -mstrict-aliasing if your
code is written according to the rules for ANSI C.
There are many other optimizations in the compiler that will break code
that doesn't meet the standard; I don't see why we should make an
exception for this one.
R.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-30 1:37 ` Andris Pavenis
@ 1999-10-31 23:35 ` Andris Pavenis
0 siblings, 0 replies; 24+ messages in thread
From: Andris Pavenis @ 1999-10-31 23:35 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: Mark Mitchell, nbecker, gcc
On Sat, 30 Oct 1999, Gerald Pfeifer wrote:
> On Wed, 27 Oct 1999, Andris Pavenis wrote:
> > Perhaps one who needs -fstrict-aliasing with 2.95.2 could simply modify
> > specs by adding '%(!no-strict-aliasing: -fstrict-aliasing)' to cc1_spec
Sorry I had typo here. It should be:
%{!no-strict-aliasing: -fstrict-aliasing}
> > (or one can do the oposite with gcc-2.95.1 and gcc-2.95 to disable strict
> > aliasing). So the default can be simply changed.
> >
> > Maybe such hack should be mentioned in FAQ.
>
> Personally I don't think we should add that to the FAQ, but if others feel
> differently, please let me know, I don't have any strong preference.
>
> Gerald
> --
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Proposal: -O4 -> strict-aliasing
1999-10-26 5:21 Proposal: -O4 -> strict-aliasing nbecker
1999-10-26 8:50 ` Mark Mitchell
@ 1999-10-31 23:35 ` nbecker
1 sibling, 0 replies; 24+ messages in thread
From: nbecker @ 1999-10-31 23:35 UTC (permalink / raw)
To: gcc
Subject says it all.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-28 5:33 ` nbecker
1999-10-28 6:21 ` Richard Earnshaw
1999-10-28 8:14 ` Mark Mitchell
@ 1999-10-31 23:35 ` nbecker
2 siblings, 0 replies; 24+ messages in thread
From: nbecker @ 1999-10-31 23:35 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>>>>> "nbecker" == nbecker <nbecker@fred.net> writes:
nbecker> Subject says it all.
Mark> I'm not sure this is the right thing. We certainly have customers who
Mark> want -O2 and -fstrict-aliasing, but specifically don't want function
Mark> that aren't marked inline to be inlined. (And -O3 has some serious
Mark> compile-time memory usage implications.) Basically, I don't think
Mark> this optimization falls into a total ordering above
Mark> -finline-functions.
I understand your point. There is almost never a perfect mapping from
a multidimensional space to a one dimensional space. But I think the
proposal is a good one.
0) no opt
1) quick/simple opt
2) extensive/expensive opt
3) opt that may increase code size
4) potentially dangerous opt
Sure, it won't suit every need, but I think it's sensible and will be
useful to the vast majority of users.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-26 8:50 ` Mark Mitchell
1999-10-27 0:18 ` Andris Pavenis
1999-10-28 5:33 ` nbecker
@ 1999-10-31 23:35 ` Mark Mitchell
2 siblings, 0 replies; 24+ messages in thread
From: Mark Mitchell @ 1999-10-31 23:35 UTC (permalink / raw)
To: nbecker; +Cc: gcc
>>>>> "nbecker" == nbecker <nbecker@fred.net> writes:
nbecker> Subject says it all.
I'm not sure this is the right thing. We certainly have customers who
want -O2 and -fstrict-aliasing, but specifically don't want function
that aren't marked inline to be inlined. (And -O3 has some serious
compile-time memory usage implications.) Basically, I don't think
this optimization falls into a total ordering above
-finline-functions.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-29 18:22 ` Gerald Pfeifer
1999-10-30 1:37 ` Andris Pavenis
1999-10-31 17:41 ` Alexandre Oliva
@ 1999-10-31 23:35 ` Gerald Pfeifer
2 siblings, 0 replies; 24+ messages in thread
From: Gerald Pfeifer @ 1999-10-31 23:35 UTC (permalink / raw)
To: Andris Pavenis; +Cc: Mark Mitchell, nbecker, gcc
On Wed, 27 Oct 1999, Andris Pavenis wrote:
> Perhaps one who needs -fstrict-aliasing with 2.95.2 could simply modify
> specs by adding '%(!no-strict-aliasing: -fstrict-aliasing)' to cc1_spec
> (or one can do the oposite with gcc-2.95.1 and gcc-2.95 to disable strict
> aliasing). So the default can be simply changed.
>
> Maybe such hack should be mentioned in FAQ.
Personally I don't think we should add that to the FAQ, but if others feel
differently, please let me know, I don't have any strong preference.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-31 17:41 ` Alexandre Oliva
@ 1999-10-31 23:35 ` Alexandre Oliva
0 siblings, 0 replies; 24+ messages in thread
From: Alexandre Oliva @ 1999-10-31 23:35 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: Andris Pavenis, Mark Mitchell, nbecker, gcc
On Oct 29, 1999, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:
> On Wed, 27 Oct 1999, Andris Pavenis wrote:
>> Perhaps one who needs -fstrict-aliasing with 2.95.2 could simply modify
>> specs by adding '%(!no-strict-aliasing: -fstrict-aliasing)' to cc1_spec
>> (or one can do the oposite with gcc-2.95.1 and gcc-2.95 to disable strict
>> aliasing). So the default can be simply changed.
>>
>> Maybe such hack should be mentioned in FAQ.
> Personally I don't think we should add that to the FAQ, but if others feel
> differently, please let me know, I don't have any strong preference.
Someone wrote before that we shouldn't teach people to modify their
spec files, as this generally leads to irreproducible bug reports,
because of the hidden arguments passed to the compiler.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-27 0:18 ` Andris Pavenis
1999-10-29 18:22 ` Gerald Pfeifer
@ 1999-10-31 23:35 ` Andris Pavenis
1 sibling, 0 replies; 24+ messages in thread
From: Andris Pavenis @ 1999-10-31 23:35 UTC (permalink / raw)
To: Mark Mitchell, nbecker; +Cc: gcc
On Tue, 26 Oct 1999, Mark Mitchell wrote:
> >>>>> "nbecker" == nbecker <nbecker@fred.net> writes:
>
> nbecker> Subject says it all.
>
> I'm not sure this is the right thing. We certainly have customers who
> want -O2 and -fstrict-aliasing, but specifically don't want function
> that aren't marked inline to be inlined. (And -O3 has some serious
> compile-time memory usage implications.) Basically, I don't think
> this optimization falls into a total ordering above
> -finline-functions.
>
Perhaps one who needs -fstrict-aliasing with 2.95.2 could simply modify
specs by adding '%(!no-strict-aliasing: -fstrict-aliasing)' to cc1_spec
(or one can do the oposite with gcc-2.95.1 and gcc-2.95 to disable strict
aliasing). So the default can be simply changed.
Maybe such hack should be mentioned in FAQ.
Andris
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-28 7:27 Mike Stump
@ 1999-10-31 23:35 ` Mike Stump
0 siblings, 0 replies; 24+ messages in thread
From: Mike Stump @ 1999-10-31 23:35 UTC (permalink / raw)
To: mark, nbecker; +Cc: gcc
> To: Mark Mitchell <mark@codesourcery.com>
> From: nbecker@fred.net
> Date: 28 Oct 1999 08:32:59 -0400
> 4) potentially dangerous opt
Please, don't use these words, they have a tendency to confuse new
users. Use the term `newer optimizations that haven't been around for
more than 20 years', or some other such notion. ;-P
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-28 9:29 ` Marc Espie
@ 1999-10-31 23:35 ` Marc Espie
0 siblings, 0 replies; 24+ messages in thread
From: Marc Espie @ 1999-10-31 23:35 UTC (permalink / raw)
To: schd; +Cc: egcs
In article < 199910281246.OAA15434@aras.mra.man.de > you write:
>>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
> Mark> I'm not sure this is the right thing. We certainly have
>customers who Mark> want -O2 and -fstrict-aliasing, but specifically
>don't want function
> Mark> that aren't marked inline to be inlined. (And -O3 has some serious
> Mark> compile-time memory usage implications.) Basically, I don't think
> Mark> this optimization falls into a total ordering above
> Mark> -finline-functions.
>
>Just a thought: Making -O4 imply strict-aliasing as proposed does not mean
>that -O2 -fstrict-aliasing isn't possible any more.
>
making -O4 (arbitrarily) imply -fstrict-aliasing is a kludge-over-a-kludge.
I've been advocating removing -fstrict-aliasing from the default optimizations
for now, as knowledgeable users will turn it back on, and naive users don't
get bitten.
There is ABSOLUTELY *no* rationale to arbitrarily put -fstrict-aliasing at
-O4, or -O42, for that matter.
Right now, the various -O levels are defined in terms of purpose, -O
for simple optimizations, -O2 for good optimisations, -O3 for optimisations
that trade-off speed for size...
The only `dangerous' optimisations (-ffast-math) have their own separate
flags, and nobody ever thought of integrating it into -O42...
This doesn't make any sense.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-28 5:46 Dietmar P. Schindler
1999-10-28 9:29 ` Marc Espie
@ 1999-10-31 23:35 ` Dietmar P. Schindler
1 sibling, 0 replies; 24+ messages in thread
From: Dietmar P. Schindler @ 1999-10-31 23:35 UTC (permalink / raw)
To: gcc
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
Mark> I'm not sure this is the right thing. We certainly have customers who Mark> want -O2 and -fstrict-aliasing, but specifically don't want function
Mark> that aren't marked inline to be inlined. (And -O3 has some serious
Mark> compile-time memory usage implications.) Basically, I don't think
Mark> this optimization falls into a total ordering above
Mark> -finline-functions.
Just a thought: Making -O4 imply strict-aliasing as proposed does not mean
that -O2 -fstrict-aliasing isn't possible any more.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
1999-10-28 5:46 Dietmar P. Schindler
@ 1999-10-28 9:29 ` Marc Espie
1999-10-31 23:35 ` Marc Espie
1999-10-31 23:35 ` Dietmar P. Schindler
1 sibling, 1 reply; 24+ messages in thread
From: Marc Espie @ 1999-10-28 9:29 UTC (permalink / raw)
To: schd; +Cc: egcs
In article < 199910281246.OAA15434@aras.mra.man.de > you write:
>>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
> Mark> I'm not sure this is the right thing. We certainly have
>customers who Mark> want -O2 and -fstrict-aliasing, but specifically
>don't want function
> Mark> that aren't marked inline to be inlined. (And -O3 has some serious
> Mark> compile-time memory usage implications.) Basically, I don't think
> Mark> this optimization falls into a total ordering above
> Mark> -finline-functions.
>
>Just a thought: Making -O4 imply strict-aliasing as proposed does not mean
>that -O2 -fstrict-aliasing isn't possible any more.
>
making -O4 (arbitrarily) imply -fstrict-aliasing is a kludge-over-a-kludge.
I've been advocating removing -fstrict-aliasing from the default optimizations
for now, as knowledgeable users will turn it back on, and naive users don't
get bitten.
There is ABSOLUTELY *no* rationale to arbitrarily put -fstrict-aliasing at
-O4, or -O42, for that matter.
Right now, the various -O levels are defined in terms of purpose, -O
for simple optimizations, -O2 for good optimisations, -O3 for optimisations
that trade-off speed for size...
The only `dangerous' optimisations (-ffast-math) have their own separate
flags, and nobody ever thought of integrating it into -O42...
This doesn't make any sense.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
@ 1999-10-28 7:27 Mike Stump
1999-10-31 23:35 ` Mike Stump
0 siblings, 1 reply; 24+ messages in thread
From: Mike Stump @ 1999-10-28 7:27 UTC (permalink / raw)
To: mark, nbecker; +Cc: gcc
> To: Mark Mitchell <mark@codesourcery.com>
> From: nbecker@fred.net
> Date: 28 Oct 1999 08:32:59 -0400
> 4) potentially dangerous opt
Please, don't use these words, they have a tendency to confuse new
users. Use the term `newer optimizations that haven't been around for
more than 20 years', or some other such notion. ;-P
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Proposal: -O4 -> strict-aliasing
@ 1999-10-28 5:46 Dietmar P. Schindler
1999-10-28 9:29 ` Marc Espie
1999-10-31 23:35 ` Dietmar P. Schindler
0 siblings, 2 replies; 24+ messages in thread
From: Dietmar P. Schindler @ 1999-10-28 5:46 UTC (permalink / raw)
To: gcc
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
Mark> I'm not sure this is the right thing. We certainly have customers who Mark> want -O2 and -fstrict-aliasing, but specifically don't want function
Mark> that aren't marked inline to be inlined. (And -O3 has some serious
Mark> compile-time memory usage implications.) Basically, I don't think
Mark> this optimization falls into a total ordering above
Mark> -finline-functions.
Just a thought: Making -O4 imply strict-aliasing as proposed does not mean
that -O2 -fstrict-aliasing isn't possible any more.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~1999-10-31 23:35 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-10-26 5:21 Proposal: -O4 -> strict-aliasing nbecker
1999-10-26 8:50 ` Mark Mitchell
1999-10-27 0:18 ` Andris Pavenis
1999-10-29 18:22 ` Gerald Pfeifer
1999-10-30 1:37 ` Andris Pavenis
1999-10-31 23:35 ` Andris Pavenis
1999-10-31 17:41 ` Alexandre Oliva
1999-10-31 23:35 ` Alexandre Oliva
1999-10-31 23:35 ` Gerald Pfeifer
1999-10-31 23:35 ` Andris Pavenis
1999-10-28 5:33 ` nbecker
1999-10-28 6:21 ` Richard Earnshaw
1999-10-31 23:35 ` Richard Earnshaw
1999-10-28 8:14 ` Mark Mitchell
1999-10-31 23:35 ` Mark Mitchell
1999-10-31 23:35 ` nbecker
1999-10-31 23:35 ` Mark Mitchell
1999-10-31 23:35 ` nbecker
1999-10-28 5:46 Dietmar P. Schindler
1999-10-28 9:29 ` Marc Espie
1999-10-31 23:35 ` Marc Espie
1999-10-31 23:35 ` Dietmar P. Schindler
1999-10-28 7:27 Mike Stump
1999-10-31 23:35 ` Mike Stump
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).