This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]