Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[David Brown <david@westcontrol.com>]

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