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@xxxxxxxxxxxxxxx>
À : Ian Lance Taylor <iant@xxxxxxxxxx>
Cc : Georg-Johann Lay <avr@xxxxxxxx>; gcc-help@xxxxxxxxxxx; charfiasma@xxxxxxxx
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@xxxxxxxxxxxxxxx> 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
