* Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
[not found] <1316712613.83211.YahooMailNeo@web28503.mail.ukl.yahoo.com>
@ 2011-09-22 19:59 ` charfi asma
2011-09-22 20:51 ` Ian Lance Taylor
2011-09-23 7:04 ` David Brown
0 siblings, 2 replies; 21+ messages in thread
From: charfi asma @ 2011-09-22 19:59 UTC (permalink / raw)
To: gcc-help
hello,
If GCC could optimize this code
if (x=1)
{
a=b;
c=d;
e=f;
foo();
}
if (x=2)
{
a=b;
c=d;
e=f;
foo();
}
to this one
if (x=1) || (x=2)
{
a=b;
c=d;
e=f;
foo();
}
it will be implemented in which optimizations ? pre: partiel redundent elimination optimizaion or another one may be code motion ?
thank you very much
Asma
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-22 19:59 ` Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations charfi asma
@ 2011-09-22 20:51 ` Ian Lance Taylor
2011-09-23 7:04 ` David Brown
1 sibling, 0 replies; 21+ messages in thread
From: Ian Lance Taylor @ 2011-09-22 20:51 UTC (permalink / raw)
To: charfi asma; +Cc: gcc-help
charfi asma <charfiasma@yahoo.fr> writes:
> If GCC could optimize this code
>
>
> if (x=1)
> {
> a=b;
> c=d;
> e=f;
> foo();
>
> }
> if (x=2)
> {
> a=b;
> c=d;
> e=f;
> foo();
> }
>
>
> to this one
>
>
> if (x=1) || (x=2)
> {
> a=b;
> c=d;
> e=f;
> foo();
> }
>
> it will be implemented in which optimizations ? pre: partiel redundent elimination optimizaion or another one may be code motion ?
I don't think gcc can do that optimization today. There used be an
optimization -frtl-abstract-sequences which was vaguely similar, but it
didn't work well and was removed. If this were to be implemented, it
would not be any of the existing optimizations; it would be something
different.
Ian
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-22 19:59 ` Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations charfi asma
2011-09-22 20:51 ` Ian Lance Taylor
@ 2011-09-23 7:04 ` David Brown
2011-09-23 8:47 ` Georg-Johann Lay
1 sibling, 1 reply; 21+ messages in thread
From: David Brown @ 2011-09-23 7:04 UTC (permalink / raw)
To: gcc-help
On 22/09/2011 21:59, charfi asma wrote:
> hello,
>
> If GCC could optimize this code
>
>
> if (x=1) { a=b; c=d; e=f; foo(); }
> if (x=2) { a=b; c=d; e=f; foo(); }
>
>
> to this one
>
> if (x=1) || (x=2) { a=b; c=d; e=f; foo(); }
>
> it will be implemented in which optimizations ? pre: partiel
> redundent elimination optimizaion or another one may be code motion?
>
> thank you very much
>
> Asma
>
gcc can't optimize code like this, because the two sequences have
different effects. In the first case, both sections are executed -
first it sets "x" to 1, then does the {a=b;...foo();} code. Then it
sets "x" to 2 and does it again. Depending on the locality and linkage
of the variables, the compiler may be able to eliminate some of the
assignments. It will certainly be able to eliminate the conditional
checks (unless "x" is volatile). Your second sequence will only execute
the code once (after the missing parenthesis are added).
If you had meant to write "if (x == 1)" instead of "if (x = 1)", then
the question makes a little more sense. But even then, it depends on
whether foo() can access or change "x" (or more precisely, it depends on
whether or not the compiler can be sure that foo() cannot read or change
"x").
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-23 7:04 ` David Brown
@ 2011-09-23 8:47 ` Georg-Johann Lay
2011-09-23 9:13 ` David Brown
0 siblings, 1 reply; 21+ messages in thread
From: Georg-Johann Lay @ 2011-09-23 8:47 UTC (permalink / raw)
To: David Brown; +Cc: gcc-help, charfiasma
David Brown schrieb:
> On 22/09/2011 21:59, charfi asma wrote:
>> hello,
>>
>> If GCC could optimize this code
>>
>>
>> if (x=1) { a=b; c=d; e=f; foo(); }
>> if (x=2) { a=b; c=d; e=f; foo(); }
>>
>>
>> to this one
>>
>> if (x=1) || (x=2) { a=b; c=d; e=f; foo(); }
>>
>> it will be implemented in which optimizations ? pre: partiel
>> redundent elimination optimizaion or another one may be code motion?
>>
>> thank you very much
>>
>> Asma
>>
> gcc can't optimize code like this, because the two sequences have
> different effects. In the first case, both sections are executed -
> first it sets "x" to 1, then does the {a=b;...foo();} code. Then it
> sets "x" to 2 and does it again. Depending on the locality and linkage
> of the variables, the compiler may be able to eliminate some of the
> assignments. It will certainly be able to eliminate the conditional
> checks (unless "x" is volatile). Your second sequence will only execute
> the code once (after the missing parenthesis are added).
>
> If you had meant to write "if (x == 1)" instead of "if (x = 1)", then
> the question makes a little more sense. But even then, it depends on
> whether foo() can access or change "x" (or more precisely, it depends on
> whether or not the compiler can be sure that foo() cannot read or change
> "x").
It's the same for
if (x == 1) { a=b; c=d; e=f; foo(); }
else if (x == 2) { a=b; c=d; e=f; foo(); }
GCC don't factor out the common part
Johann
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-23 8:47 ` Georg-Johann Lay
@ 2011-09-23 9:13 ` David Brown
2011-09-23 15:16 ` David Brown
2011-09-23 15:53 ` Ian Lance Taylor
0 siblings, 2 replies; 21+ messages in thread
From: David Brown @ 2011-09-23 9:13 UTC (permalink / raw)
To: Georg-Johann Lay; +Cc: gcc-help, charfiasma
On 23/09/2011 10:46, Georg-Johann Lay wrote:
> David Brown schrieb:
>> On 22/09/2011 21:59, charfi asma wrote:
>>> hello,
>>>
>>> If GCC could optimize this code
>>>
>>>
>>> if (x=1) { a=b; c=d; e=f; foo(); }
>>> if (x=2) { a=b; c=d; e=f; foo(); }
>>>
>>>
>>> to this one
>>>
>>> if (x=1) || (x=2) { a=b; c=d; e=f; foo(); }
>>>
>>> it will be implemented in which optimizations ? pre: partiel
>>> redundent elimination optimizaion or another one may be code motion?
>>>
>>> thank you very much
>>>
>>> Asma
>>>
>> gcc can't optimize code like this, because the two sequences have
>> different effects. In the first case, both sections are executed -
>> first it sets "x" to 1, then does the {a=b;...foo();} code. Then it
>> sets "x" to 2 and does it again. Depending on the locality and linkage
>> of the variables, the compiler may be able to eliminate some of the
>> assignments. It will certainly be able to eliminate the conditional
>> checks (unless "x" is volatile). Your second sequence will only execute
>> the code once (after the missing parenthesis are added).
>>
>> If you had meant to write "if (x == 1)" instead of "if (x = 1)", then
>> the question makes a little more sense. But even then, it depends on
>> whether foo() can access or change "x" (or more precisely, it depends on
>> whether or not the compiler can be sure that foo() cannot read or change
>> "x").
>
> It's the same for
>
> if (x == 1) { a=b; c=d; e=f; foo(); }
> else if (x == 2) { a=b; c=d; e=f; foo(); }
>
> GCC don't factor out the common part
>
You are right - which is odd, since there is no reason why it could not
(unlike the original case where there is no "else"). Surely this would
count as a significant missed optimisation, especially for big switch()
code.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-23 9:13 ` David Brown
@ 2011-09-23 15:16 ` David Brown
2011-09-23 15:53 ` Ian Lance Taylor
1 sibling, 0 replies; 21+ messages in thread
From: David Brown @ 2011-09-23 15:16 UTC (permalink / raw)
To: gcc-help; +Cc: gcc-help, charfiasma
On 23/09/2011 10:46, Georg-Johann Lay wrote:
> David Brown schrieb:
>> On 22/09/2011 21:59, charfi asma wrote:
>>> hello,
>>>
>>> If GCC could optimize this code
>>>
>>>
>>> if (x=1) { a=b; c=d; e=f; foo(); }
>>> if (x=2) { a=b; c=d; e=f; foo(); }
>>>
>>>
>>> to this one
>>>
>>> if (x=1) || (x=2) { a=b; c=d; e=f; foo(); }
>>>
>>> it will be implemented in which optimizations ? pre: partiel
>>> redundent elimination optimizaion or another one may be code motion?
>>>
>>> thank you very much
>>>
>>> Asma
>>>
>> gcc can't optimize code like this, because the two sequences have
>> different effects. In the first case, both sections are executed -
>> first it sets "x" to 1, then does the {a=b;...foo();} code. Then it
>> sets "x" to 2 and does it again. Depending on the locality and linkage
>> of the variables, the compiler may be able to eliminate some of the
>> assignments. It will certainly be able to eliminate the conditional
>> checks (unless "x" is volatile). Your second sequence will only execute
>> the code once (after the missing parenthesis are added).
>>
>> If you had meant to write "if (x == 1)" instead of "if (x = 1)", then
>> the question makes a little more sense. But even then, it depends on
>> whether foo() can access or change "x" (or more precisely, it depends on
>> whether or not the compiler can be sure that foo() cannot read or change
>> "x").
>
> It's the same for
>
> if (x == 1) { a=b; c=d; e=f; foo(); }
> else if (x == 2) { a=b; c=d; e=f; foo(); }
>
> GCC don't factor out the common part
>
You are right - which is odd, since there is no reason why it could not
(unlike the original case where there is no "else"). Surely this would
count as a significant missed optimisation, especially for big switch()
code.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-23 9:13 ` David Brown
2011-09-23 15:16 ` David Brown
@ 2011-09-23 15:53 ` Ian Lance Taylor
2011-09-23 16:05 ` Jeff Kenton
2011-09-25 13:31 ` David Brown
1 sibling, 2 replies; 21+ messages in thread
From: Ian Lance Taylor @ 2011-09-23 15:53 UTC (permalink / raw)
To: David Brown; +Cc: Georg-Johann Lay, gcc-help, charfiasma
David Brown <david@westcontrol.com> writes:
>> It's the same for
>>
>> if (x == 1) { a=b; c=d; e=f; foo(); }
>> else if (x == 2) { a=b; c=d; e=f; foo(); }
>>
>> GCC don't factor out the common part
>>
>
> You are right - which is odd, since there is no reason why it could
> not (unlike the original case where there is no "else"). Surely this
> would count as a significant missed optimisation, especially for big
> switch() code.
I don't think it is a significant missed optimization, as people rarely
write code like that. They normally write
if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
The proposed optimization only applies when somebody has laboriously
written out the exact same sequence of code twice.
I'm not opposed to such an optimization if it works reliably and is not
too expensive. I just don't think it will make much difference on
ordinary code.
Ian
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-23 15:53 ` Ian Lance Taylor
@ 2011-09-23 16:05 ` Jeff Kenton
2011-09-23 19:03 ` Jeff Law
2011-09-25 13:31 ` David Brown
1 sibling, 1 reply; 21+ messages in thread
From: Jeff Kenton @ 2011-09-23 16:05 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: David Brown, Georg-Johann Lay, gcc-help, charfiasma
On 09/23/2011 11:16 AM, Ian Lance Taylor wrote:
> David Brown<david@westcontrol.com> writes:
>
>>> It's the same for
>>>
>>> if (x == 1) { a=b; c=d; e=f; foo(); }
>>> else if (x == 2) { a=b; c=d; e=f; foo(); }
>>>
>>> GCC don't factor out the common part
>>>
>> You are right - which is odd, since there is no reason why it could
>> not (unlike the original case where there is no "else"). Surely this
>> would count as a significant missed optimisation, especially for big
>> switch() code.
> I don't think it is a significant missed optimization, as people rarely
> write code like that. They normally write
>
> if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>
> The proposed optimization only applies when somebody has laboriously
> written out the exact same sequence of code twice.
>
> I'm not opposed to such an optimization if it works reliably and is not
> too expensive. I just don't think it will make much difference on
> ordinary code.
>
> Ian
People don't write that kind of code (we hope), but machine generated
code can have all kinds of weirdness. Still not a big deal, but it
might be more common than you think.
--jeff
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-23 16:05 ` Jeff Kenton
@ 2011-09-23 19:03 ` Jeff Law
2011-09-27 7:18 ` Miles Bader
0 siblings, 1 reply; 21+ messages in thread
From: Jeff Law @ 2011-09-23 19:03 UTC (permalink / raw)
To: Jeff Kenton
Cc: Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help, charfiasma
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/23/11 09:53, Jeff Kenton wrote:
> On 09/23/2011 11:16 AM, Ian Lance Taylor wrote:
>> David Brown<david@westcontrol.com> writes:
>>
>>>> It's the same for
>>>>
>>>> if (x == 1) { a=b; c=d; e=f; foo(); } else if (x == 2) {
>>>> a=b; c=d; e=f; foo(); }
>>>>
>>>> GCC don't factor out the common part
>>>>
>>> You are right - which is odd, since there is no reason why it
>>> could not (unlike the original case where there is no "else").
>>> Surely this would count as a significant missed optimisation,
>>> especially for big switch() code.
>> I don't think it is a significant missed optimization, as people
>> rarely write code like that. They normally write
>>
>> if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>>
>> The proposed optimization only applies when somebody has
>> laboriously written out the exact same sequence of code twice.
>>
>> I'm not opposed to such an optimization if it works reliably and
>> is not too expensive. I just don't think it will make much
>> difference on ordinary code.
>>
>> Ian
>
> People don't write that kind of code (we hope), but machine
> generated code can have all kinds of weirdness. Still not a big
> deal, but it might be more common than you think.
The tail merging code in the RTL optimizers might pick this stuff up
and Tom's work on block merging might as well. It'd be worth looking
into why they aren't triggering.
jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOfK5HAAoJEBRtltQi2kC7pbIH/1tT4EPQlxJaUqlW4Strw6aE
1XfD5YHlcwnMvcbDbmZuglRVtQN+YZptw7rWfJ/47Pvad4yuzvOUmhQKUyYCd0q+
7bXXBDNP9irxoDOOuU5EA9678ZFIiCCDVFAy/ld3WmiP5UQ+Zkx4GEPwsWoIjmvh
umcCRFFQXK+Kosnxcqk9cbhYRg3/9aaP2FSuthoveZbRk9cZQcQyfyxz9RMaCli+
hFe6wh/l7d8h+8WUummebV9B5y+zKehtXH3G+f43EyWKm8LwnNPLLj6dU/1J/6IB
OPrPjgCLAbz+k7P28VpzSfW18td3wMnBFioE3t89PdJfQwTgYK1wC3iIdVkm8RA=
=we18
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-23 15:53 ` Ian Lance Taylor
2011-09-23 16:05 ` Jeff Kenton
@ 2011-09-25 13:31 ` David Brown
2011-09-25 13:50 ` David Brown
2011-09-26 10:57 ` Re : " charfi asma
1 sibling, 2 replies; 21+ messages in thread
From: David Brown @ 2011-09-25 13:31 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Georg-Johann Lay, gcc-help, charfiasma
On 23/09/2011 17:16, Ian Lance Taylor wrote:
> David Brown<david@westcontrol.com> writes:
>
>>> It's the same for
>>>
>>> if (x == 1) { a=b; c=d; e=f; foo(); }
>>> else if (x == 2) { a=b; c=d; e=f; foo(); }
>>>
>>> GCC don't factor out the common part
>>>
>>
>> You are right - which is odd, since there is no reason why it could
>> not (unlike the original case where there is no "else"). Surely this
>> would count as a significant missed optimisation, especially for big
>> switch() code.
>
> I don't think it is a significant missed optimization, as people rarely
> write code like that. They normally write
>
> if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>
> The proposed optimization only applies when somebody has laboriously
> written out the exact same sequence of code twice.
>
> I'm not opposed to such an optimization if it works reliably and is not
> too expensive. I just don't think it will make much difference on
> ordinary code.
>
> Ian
>
When you are talking about a simple case like this, then I agree. The
situation where I would expect to see it more is in switch statements
where for various reasons you might have the same code for different
cases, but have them separated for some reason. Even more common is the
situation when you have some commonality between the branches, but not
completely identical cases. The "tail merging" and "block merging"
mentioned by Jeff Law sounds like optimisations to suit such cases.
It is always possible that these optimisations /are/ triggered by such
code for current and development versions of gcc - the compiler I tested
with was gcc 4.5.1 (since that's the version I have conveniently
available at the moment).
David
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-25 13:31 ` David Brown
@ 2011-09-25 13:50 ` David Brown
2011-09-26 10:57 ` Re : " charfi asma
1 sibling, 0 replies; 21+ messages in thread
From: David Brown @ 2011-09-25 13:50 UTC (permalink / raw)
To: gcc-help; +Cc: Georg-Johann Lay, gcc-help, charfiasma
On 23/09/2011 17:16, Ian Lance Taylor wrote:
> David Brown<david@westcontrol.com> writes:
>
>>> It's the same for
>>>
>>> if (x == 1) { a=b; c=d; e=f; foo(); }
>>> else if (x == 2) { a=b; c=d; e=f; foo(); }
>>>
>>> GCC don't factor out the common part
>>>
>>
>> You are right - which is odd, since there is no reason why it could
>> not (unlike the original case where there is no "else"). Surely this
>> would count as a significant missed optimisation, especially for big
>> switch() code.
>
> I don't think it is a significant missed optimization, as people rarely
> write code like that. They normally write
>
> if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>
> The proposed optimization only applies when somebody has laboriously
> written out the exact same sequence of code twice.
>
> I'm not opposed to such an optimization if it works reliably and is not
> too expensive. I just don't think it will make much difference on
> ordinary code.
>
> Ian
>
When you are talking about a simple case like this, then I agree. The
situation where I would expect to see it more is in switch statements
where for various reasons you might have the same code for different
cases, but have them separated for some reason. Even more common is the
situation when you have some commonality between the branches, but not
completely identical cases. The "tail merging" and "block merging"
mentioned by Jeff Law sounds like optimisations to suit such cases.
It is always possible that these optimisations /are/ triggered by such
code for current and development versions of gcc - the compiler I tested
with was gcc 4.5.1 (since that's the version I have conveniently
available at the moment).
David
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-25 13:31 ` David Brown
2011-09-25 13:50 ` David Brown
@ 2011-09-26 10:57 ` charfi asma
2011-09-26 15:35 ` Miles Bader
2011-09-26 22:47 ` Jeff Law
1 sibling, 2 replies; 21+ messages in thread
From: charfi asma @ 2011-09-26 10:57 UTC (permalink / raw)
To: David Brown; +Cc: Ian Lance Taylor, gcc-help, Jeff Law, avr
Hello every body,
First of all, thank you for all your responses ;)
this situation is frequent in real time and embedded system development (developper use switch cas statements to express the behavior of the system).
I think that GCC purpose is to help developper to produce an optimized code for their application. developper are not obliged to optimize the code, we have to be happy if they manage to write the correct code (that runs just like developper want it to run). Otherwise, optimization is the GCC stuff...
@ David: if (x=1) was a typo, I meant if (x==1).
you said that The "tail merging" and "block merging"
mentioned by Jeff Law sounds like optimisations to suit such cases.
I tested with gcc 4.6 (the current gcc version) I compiled the code using -Os and GCC did not optimize the code. did block merging and tail merging are not included in -Os ?
thank you very much
Asma
----- Mail original -----
De : David Brown <david@westcontrol.com>
À : Ian Lance Taylor <iant@google.com>
Cc : Georg-Johann Lay <avr@gjlay.de>; gcc-help@gcc.gnu.org; charfiasma@yahoo.fr
Envoyé le : Samedi 24 Septembre 2011 17h07
Objet : Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
On 23/09/2011 17:16, Ian Lance Taylor wrote:
> David Brown<david@westcontrol.com> writes:
>
>>> It's the same for
>>>
>>> if (x == 1) { a=b; c=d; e=f; foo(); }
>>> else if (x == 2) { a=b; c=d; e=f; foo(); }
>>>
>>> GCC don't factor out the common part
>>>
>>
>> You are right - which is odd, since there is no reason why it could
>> not (unlike the original case where there is no "else"). Surely this
>> would count as a significant missed optimisation, especially for big
>> switch() code.
>
> I don't think it is a significant missed optimization, as people rarely
> write code like that. They normally write
>
> if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>
> The proposed optimization only applies when somebody has laboriously
> written out the exact same sequence of code twice.
>
> I'm not opposed to such an optimization if it works reliably and is not
> too expensive. I just don't think it will make much difference on
> ordinary code.
>
> Ian
>
When you are talking about a simple case like this, then I agree. The
situation where I would expect to see it more is in switch statements
where for various reasons you might have the same code for different
cases, but have them separated for some reason. Even more common is the
situation when you have some commonality between the branches, but not
completely identical cases. The "tail merging" and "block merging"
mentioned by Jeff Law sounds like optimisations to suit such cases.
It is always possible that these optimisations /are/ triggered by such
code for current and development versions of gcc - the compiler I tested
with was gcc 4.5.1 (since that's the version I have conveniently
available at the moment).
David
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-26 10:57 ` Re : " charfi asma
@ 2011-09-26 15:35 ` Miles Bader
2011-09-26 22:47 ` Jeff Law
1 sibling, 0 replies; 21+ messages in thread
From: Miles Bader @ 2011-09-26 15:35 UTC (permalink / raw)
To: charfi asma; +Cc: David Brown, Ian Lance Taylor, gcc-help, Jeff Law, avr
charfi asma <charfiasma@yahoo.fr> writes:
> I tested with gcc 4.6 (the current gcc version) I compiled the code
> using -Os and GCC did not optimize the code. did block merging and tail
> merging are not included in -Os ?
You should really check with a recent version of the development trunk.
[If you're using debian, this is available in the "gcc-snapshot"
package -- very handy!]
-Miles
--
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-26 10:57 ` Re : " charfi asma
2011-09-26 15:35 ` Miles Bader
@ 2011-09-26 22:47 ` Jeff Law
1 sibling, 0 replies; 21+ messages in thread
From: Jeff Law @ 2011-09-26 22:47 UTC (permalink / raw)
To: charfi asma; +Cc: David Brown, Ian Lance Taylor, gcc-help, avr
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/26/11 03:06, charfi asma wrote:
> Hello every body,
>
> First of all, thank you for all your responses ;)
>
>
> this situation is frequent in real time and embedded system
> development (developper use switch cas statements to express the
> behavior of the system).
>
> I think that GCC purpose is to help developper to produce an
> optimized code for their application. developper are not obliged to
> optimize the code, we have to be happy if they manage to write the
> correct code (that runs just like developper want it to run).
> Otherwise, optimization is the GCC stuff... @ David: if (x=1) was a
> typo, I meant if (x==1).
>
> you said that The "tail merging" and "block merging" mentioned by
> Jeff Law sounds like optimisations to suit such cases.
>
> I tested with gcc 4.6 (the current gcc version) I compiled the code
> using -Os and GCC did not optimize the code. did block merging and
> tail merging are not included in -Os ?
>
Tom's changes aren't in GCC 4.6, you'd have to test the current sources.
jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOgK3kAAoJEBRtltQi2kC7IpkH/1aZzqaHYWOgBotOntRoMsHM
SS1qmsr2AdK33tiEDCvMVRA3sfAN8s8wfhpudYK0dTL5/VG2KhNipdSHZp3N7CgX
7EYuOebVU0na1ucvBChHdCDiIXV5u81UjPr8t7fwK7x78k5/2xeuMAv2U2DvPWmk
8hH9IDzFppSWFE413gnT5ONEoYImINWaAiiAINU/OsxblTpTh4UGl7wfdygzIcGc
k3txE2fRGel07hJvy0T72MtkPuCfw2ISa262/yN4zpEIwh8nssljy4pb4Wos55Dl
IAEHNgxlAxfJoDVjpZVmqf80a8nNRa9OV1pUlN5+gYM/QABmT25QIVE2KWse3j4=
=L+dW
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-23 19:03 ` Jeff Law
@ 2011-09-27 7:18 ` Miles Bader
2011-09-27 9:35 ` Miles Bader
0 siblings, 1 reply; 21+ messages in thread
From: Miles Bader @ 2011-09-27 7:18 UTC (permalink / raw)
To: Jeff Law
Cc: Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay,
gcc-help, charfiasma
Jeff Law <law@redhat.com> writes:
> The tail merging code in the RTL optimizers might pick this stuff up
> and Tom's work on block merging might as well. It'd be worth
> looking into why they aren't triggering.
Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
two if-blocks:
int a, b, c, d, e, f;
extern void foo ();
void t (int x)
{
if (x==1) { a=b; c=d; e=f; foo(); }
if (x==2) { a=b; c=d; e=f; foo(); }
}
=>
t:
cmpl $1, %edi
je .L4
cmpl $2, %edi
je .L4
rep
ret
.L4:
movl b(%rip), %eax
movl %eax, a(%rip)
movl d(%rip), %eax
movl %eax, c(%rip)
movl f(%rip), %eax
movl %eax, e(%rip)
xorl %eax, %eax
jmp foo
...
.ident "GCC: (Debian 20110924-1) 4.7.0 20110924 (experimental) [trunk revision 179143]"
-Miles
--
Quotation, n. The act of repeating erroneously the words of another. The words
erroneously repeated.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-27 7:18 ` Miles Bader
@ 2011-09-27 9:35 ` Miles Bader
2011-09-27 11:29 ` Miles Bader
0 siblings, 1 reply; 21+ messages in thread
From: Miles Bader @ 2011-09-27 9:35 UTC (permalink / raw)
To: Jeff Law
Cc: Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay,
gcc-help, charfiasma
Miles Bader <miles@gnu.org> writes:
> Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
> two if-blocks:
...
and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same thing!
So I dunno... what's the complaint again...?
-Miles
--
((lambda (x) (list x x)) (lambda (x) (list x x)))
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-27 9:35 ` Miles Bader
@ 2011-09-27 11:29 ` Miles Bader
2011-09-27 16:47 ` Amker.Cheng
2011-09-28 0:03 ` Re : " charfi asma
0 siblings, 2 replies; 21+ messages in thread
From: Miles Bader @ 2011-09-27 11:29 UTC (permalink / raw)
To: Jeff Law
Cc: Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay,
gcc-help, charfiasma
Miles Bader <miles@gnu.org> writes:
>> Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
>> two if-blocks:
> ...
>
> and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same thing!
>
> So I dunno... what's the complaint again...?
I note that this optimization only takes place at -O2 or above; maybe
the original poster simply didn't use a high-enough optimization level?
-miles
--
I'd rather be consing.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-27 11:29 ` Miles Bader
@ 2011-09-27 16:47 ` Amker.Cheng
2011-09-27 23:42 ` Jeff Law
2011-09-28 0:03 ` Re : " charfi asma
1 sibling, 1 reply; 21+ messages in thread
From: Amker.Cheng @ 2011-09-27 16:47 UTC (permalink / raw)
To: Miles Bader
Cc: Jeff Law, Jeff Kenton, Ian Lance Taylor, David Brown,
Georg-Johann Lay, gcc-help, charfiasma
On Tue, Sep 27, 2011 at 1:12 PM, Miles Bader <miles@gnu.org> wrote:
> Miles Bader <miles@gnu.org> writes:
>>> Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
>>> two if-blocks:
>> ...
>>
>> and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same thing!
>>
>> So I dunno... what's the complaint again...?
>
> I note that this optimization only takes place at -O2 or above; maybe
> the original poster simply didn't use a high-enough optimization level?
>
> -miles
>
> --
> I'd rather be consing.
>
A case I ran into with gcc trunk after cprop1 pass:
cc <- compare(r684, 0)
if (cc != 0) goto .L1
r191 <- 0
goto .L2
.L1:
r191 <- 0
...other insns
.L2:
In my experiment, both following pre and cse passes do not hoist the
r191<-0 to the beginning.
I understand that it is actually not a redundant case, and not pre's job.
So which pass in gcc might handle it? Thanks very much.
Wondering is it a similar story to the original post?
--
Best Regards.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-27 16:47 ` Amker.Cheng
@ 2011-09-27 23:42 ` Jeff Law
0 siblings, 0 replies; 21+ messages in thread
From: Jeff Law @ 2011-09-27 23:42 UTC (permalink / raw)
To: Amker.Cheng
Cc: Miles Bader, Jeff Kenton, Ian Lance Taylor, David Brown,
Georg-Johann Lay, gcc-help, charfiasma
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/27/11 03:34, Amker.Cheng wrote:
> On Tue, Sep 27, 2011 at 1:12 PM, Miles Bader <miles@gnu.org>
> wrote:
>> Miles Bader <miles@gnu.org> writes:
>>>> Hmm, actually testing with a recent gcc snapshot, it _is_
>>>> merging the two if-blocks:
>>> ...
>>>
>>> and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same
>>> thing!
>>>
>>> So I dunno... what's the complaint again...?
>>
>> I note that this optimization only takes place at -O2 or above;
>> maybe the original poster simply didn't use a high-enough
>> optimization level?
>>
>> -miles
>>
>> -- I'd rather be consing.
>>
>
> A case I ran into with gcc trunk after cprop1 pass:
>
> cc <- compare(r684, 0) if (cc != 0) goto .L1 r191 <- 0 goto .L2
> .L1: r191 <- 0 ...other insns .L2:
>
> In my experiment, both following pre and cse passes do not hoist
> the r191<-0 to the beginning. I understand that it is actually not
> a redundant case, and not pre's job. So which pass in gcc might
> handle it? Thanks very much.
>
> Wondering is it a similar story to the original post?
What you've described is code hoisting. pre and cse aren't going to
perform this optimization because on any given path through the CFG
only one r191<-0 statement will be executed.
Typically this isn't going to be caught by block or tail merging due
to "other insns". However, there is a code hoisting pass that is
enabled by -Os which might catch this stuff.
jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOgfwlAAoJEBRtltQi2kC7t4QH/0jeYAjLu9iafjsnY/CRElMk
ImkV8VNRJvbr4mYexI5JQoF63ZM3/LUwlfrU77UwLwEL/lbGt+i695UBmOX2UP2D
Xqvhb9fQFAT57oYMOAKr2ohPWs12LiJK1bPRv3HoARJfXamLX4OFYFJsD2srHO+y
dhNrEPQRfkn8jPWB2Ib7UtX48FZG0Oy4WWOqK8yPWk1RSW3eDSI8OEVXbSRaVMOC
K8oj2QAnPy8EulwSD8E0kEo4f2IqOCiMpDy5qMY5yrDA1AQwYdu71WH1y0fOCmZj
OnCCKK16fIxQQt3ifJAa9iE1H+U44O/DsIrbTS7Y5BMhQT4zFMaa8I8BVo0PGuc=
=LadS
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-27 11:29 ` Miles Bader
2011-09-27 16:47 ` Amker.Cheng
@ 2011-09-28 0:03 ` charfi asma
2011-09-28 8:59 ` Miles Bader
1 sibling, 1 reply; 21+ messages in thread
From: charfi asma @ 2011-09-28 0:03 UTC (permalink / raw)
To: Miles Bader, Jeff Law
Cc: Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help
----- Mail original -----
De : Miles Bader <miles@gnu.org>
À : Jeff Law <law@redhat.com>
Cc : Jeff Kenton <jkenton@tilera.com>; Ian Lance Taylor <iant@google.com>; David Brown <david@westcontrol.com>; Georg-Johann Lay <avr@gjlay.de>; gcc-help@gcc.gnu.org; charfiasma@yahoo.fr
Envoyé le : Mardi 27 Septembre 2011 7h12
Objet : Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
Miles Bader <miles@gnu.org> writes:
>> Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
>> two if-blocks:
> ...
>
> and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same thing!
>
> So I dunno... what's the complaint again...?
I note that this optimization only takes place at -O2 or above; maybe
the original poster simply didn't use a high-enough optimization level?
-miles
--
I'd rather be consing.
Hello,
When I write the C code I tried to simplify the code cause actually I used nested switch cases and the code is not directly written in the main it is written in another function called in main.
this is the simplified code that GCC did not optimize when I compile the C++ code using -Os. (I used GCC: (GNU) 4.6.0 20110218 )
perhaps it deals with GCC intra optimizations ...
I am so sorry for the wrong simplification that I did (in the previous post) cause actually, GCC did factorize the common blocs as miles said but it did not factorize this example :(
int a,b,c,d;
class MyClass
{
public : int x;
public : void foo()
{
d=10;
}
public : void foo1()
{
if (x==1)
{
a=10;
b=11;
c=12;
foo();
}
if (x==2)
{
a=10;
b=11;
c=12;
foo();
}
}
};
int main()
{
MyClass c;
c.x=1;
c.foo1();
c.foo1();
c.foo1();
return 0;
}
and this is the assembly code generated from it.
.weak _ZN7MyClass4foo1Ev
.type _ZN7MyClass4foo1Ev, @function
_ZN7MyClass4foo1Ev:
.LFB1:
cmpl $1, (%rdi)
jne .L2
movl $10, a(%rip)
movl $11, b(%rip)
movl $12, c(%rip)
movl $10, d(%rip)
.L2:
cmpl $2, (%rdi)
jne .L1
movl $10, a(%rip)
movl $11, b(%rip)
movl $12, c(%rip)
movl $10, d(%rip)
.L1:
ret
.LFE1:
.size _ZN7MyClass4foo1Ev, .-_ZN7MyClass4foo1Ev
.section .text.startup,"ax",@progbits
.globl main
.type main, @function
main:
.LFB2:
subq $24, %rsp
.LCFI0:
leaq 12(%rsp), %rdi
movl $1, 12(%rsp)
call _ZN7MyClass4foo1Ev
leaq 12(%rsp), %rdi
call _ZN7MyClass4foo1Ev
leaq 12(%rsp), %rdi
call _ZN7MyClass4foo1Ev
xorl %eax, %eax
addq $24, %rsp
.LCFI1:
ret
....
LEFDE3:
.ident "GCC: (GNU) 4.6.0 20110218 (experimental)"
.section .note.GNU-stack,"",@progbits
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
2011-09-28 0:03 ` Re : " charfi asma
@ 2011-09-28 8:59 ` Miles Bader
0 siblings, 0 replies; 21+ messages in thread
From: Miles Bader @ 2011-09-28 8:59 UTC (permalink / raw)
To: charfi asma
Cc: Jeff Law, Jeff Kenton, Ian Lance Taylor, David Brown,
Georg-Johann Lay, gcc-help
charfi asma <charfiasma@yahoo.fr> writes:
> this is the simplified code that GCC did not optimize when I compile
> the C++ code using -Os. (I used GCC: (GNU) 4.6.0 20110218 ) perhaps it
> deals with GCC intra optimizations ...
Using this example code, gcc 4.6.1 also doesn't merge the if-blocks for
me either (with -O2 or -Os).
gcc 4.7 (Debian 20110924-1) _does_ merge the if-blocks with -O2, but
_not_ with -Os. [this seems slightly odd; isn't this kind of
tail-merging almost guaranteed to be a big win for -Os?]
-Mile
--
Defenceless, adj. Unable to attack.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2011-09-28 5:01 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1316712613.83211.YahooMailNeo@web28503.mail.ukl.yahoo.com>
2011-09-22 19:59 ` Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations charfi asma
2011-09-22 20:51 ` Ian Lance Taylor
2011-09-23 7:04 ` David Brown
2011-09-23 8:47 ` Georg-Johann Lay
2011-09-23 9:13 ` David Brown
2011-09-23 15:16 ` David Brown
2011-09-23 15:53 ` Ian Lance Taylor
2011-09-23 16:05 ` Jeff Kenton
2011-09-23 19:03 ` Jeff Law
2011-09-27 7:18 ` Miles Bader
2011-09-27 9:35 ` Miles Bader
2011-09-27 11:29 ` Miles Bader
2011-09-27 16:47 ` Amker.Cheng
2011-09-27 23:42 ` Jeff Law
2011-09-28 0:03 ` Re : " charfi asma
2011-09-28 8:59 ` Miles Bader
2011-09-25 13:31 ` David Brown
2011-09-25 13:50 ` David Brown
2011-09-26 10:57 ` Re : " charfi asma
2011-09-26 15:35 ` Miles Bader
2011-09-26 22:47 ` Jeff Law
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).