From: charfi asma <charfiasma@yahoo.fr>
To: David Brown <david@westcontrol.com>
Cc: Ian Lance Taylor <iant@google.com>,
"gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>,
Jeff Law <law@redhat.com>, "avr@gjlay.de" <avr@gjlay.de>
Subject: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations
Date: Mon, 26 Sep 2011 10:57:00 -0000 [thread overview]
Message-ID: <1317028000.29029.YahooMailNeo@web28511.mail.ukl.yahoo.com> (raw)
In-Reply-To: <4E7DF22E.2010307@westcontrol.com>
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
next prev parent reply other threads:[~2011-09-26 9:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[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
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 ` charfi asma [this message]
2011-09-26 15:35 ` Re : " Miles Bader
2011-09-26 22:47 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1317028000.29029.YahooMailNeo@web28511.mail.ukl.yahoo.com \
--to=charfiasma@yahoo.fr \
--cc=avr@gjlay.de \
--cc=david@westcontrol.com \
--cc=gcc-help@gcc.gnu.org \
--cc=iant@google.com \
--cc=law@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).