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

[David Brown]

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.