Using fold() in frontends
Joseph S. Myers
joseph@codesourcery.com
Mon Mar 7 18:24:00 GMT 2005
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/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
More information about the Gcc
mailing list