On Mon, 7 Mar 2005, Richard Kenner wrote: > What I thought we agreed on was *only* that if a language has rules about > what *must* be a constant, we should not be depending on fold to be part > of the enforcement for those rules.
A language has rules about what must be a constant. It has rules about what must not be a constant. It has, as in the current discussions, rules about what must or must not be an lvalue. It has rules about what operations on constants are or are not undefined (in C99, left shift of negative integers is undefined behavior; we don't use this for optimization and I doubt there would be significant value in doing so but I think this does mean we need to treat expressions such as -1 << 0 as overflowing and not being pedantically constant). We may want to do some folding at gimplification time, as it's the last point at which we can readily rearrange the order of evaluation of subexpressions in cases where that helps and the language permits; for such rearrangement to be possible afterwards we'd need to use sequence point rules to generate aliasing information. (E.g., in the expression ++*p + ++*q we can assume that p and q don't alias.) We also want to do some folding at later stages on SSA trees to take advantage of information found by SSA optimizations. But folding during parsing and semantic analysis, beyond that required by the language standard, is hobbled by such matters as needing to preserve language-specific lvalue-nature - for example, needing to keep a COND_EXPR in a form which the C++ front end understands as a lvalue if the original COND_EXPR was one. If instead all parsing and semantic analysis, and transformation of e.g. COND_EXPR used as lvalue into valid GENERIC, are carried out before folding, fold doesn't need to concern itself with preserving language-specific properties of the trees. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
