http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283
--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-02-16 20:10:34 UTC --- On Thu, 16 Feb 2012, manu at gcc dot gnu.org wrote: > Is this folding actually necessary for anything beyond diagnostics? I thought > it was agreed that folding in the FEs was EVIL and we should stop doing it. Folding with c_fully_fold is done (a) where required for language semantics (in particular integer constant expressions ... remember that it's not possible to avoid doing struct layout quite early, for example, even if it would seem cleaner to have separate phases there, because offsetof can be used in an integer constant expression, and whether such an expression evaluates to 0 affects the types of other expressions), (b) for diagnostics (folded expressions work better in various cases that try to avoid diagnostics for e.g. signed/unsigned conversions that can't actually cause any problems), (c) in certain cases where the expression being built up is something such as SAVE_EXPR it would be problematic for the front end to try to take apart to fold inside later and (d) as a final lowering stage for a full expression that converts it into the form that will be gimplified. > I wouldn't be surprised if the compiler got noticeably faster by removing all > early folding and all the workarounds and hacks that come with it, and > replacing it by doing a temporary c_fully_fold at those specific places that > needed it (and throwing away the result and keeping the original code around). The places that use c_fully_fold on something less than a full expression are doing it because it's actually needed there and removing it will break things. Furthermore, if you throw away the result as you suggest, so repeatedly folding the same expression as a subexpression of larger expressions, you would be liable to make things slower. (When c_fully_fold is run on something less than a full expression, the result is wrapped so that it *doesn't* recurse inside that subexpression when called on a larger expression containing it.) For cases in (c) it may be useful to create new C-family tree codes that represent the operations in question at a level closer to the C source code, so allowing the lowering to SAVE_EXPR etc. to be delayed until a later c_fully_fold call. For (b), it may be useful to create codes representing that a conversion was implicit, or that a diagnostic should be generated under certain conditions, again either processing them later in c_fully_fold or passing down the "diagnose this if ..." information for diagnostics to be generated at a later stage if the code is still reachable after some optimization and the compiler can't rule out whatever the problem is - but doing things any later than the final lowering to GENERIC / GIMPLE runs into the usual trade-offs between predictable diagnostics and avoiding diagnostics where a human can see there is no problem. In any case you can't just remove the folding without creating appropriate new representations.
