Re: fold() and target-specific macros

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> Sure, but simply limiting fold() to the folding required by the
Andrew> language won't necessarily get us everything we need (for, say,
Andrew> efficient aggregate initialization) and might well lead to missed
Andrew> optimization opportunities.

Yeah, I agree.  My proposal has two parts: a java-specific fold()
replacement which implements precisely the semantics required by the
language.  java_fold() is the only folder called during semantic
analysis of Java source code.  Then, once we've lowered to generic
and/or gimple -- and are thus definitely not going to be writing
bytecode -- we can call the gcc fold() to do its various
target-specific tweaks and whatnot.

I think this makes sense for a few reasons.  First, gcc's fold() will
never do exactly what Java needs.  Second, gcc's fold() has two
purposes, as far as I can tell: constant folding and optimization, but
we only need the former for semantic analysis and when generating
bytecode... which leads to the third reason, namely that I think there
aren't very many optimization opportunities to be had when generating
bytecode.  For instance, aggregate initialization doesn't exist as
such (in fact this was the cause of the bit field problem we had to
work around with a langhook).

Andrew> We've known for a long time that a Java-specific folder would be
Andrew> useful.  However, the idea of every programming language having a
Andrew> folder that does the same thing in many (most?) cases is rather
Andrew> appalling.

Yeah.

Andrew> Perhaps it would be better to have a common fold library that
Andrew> language-specific folders could use.

Yeah.  We would probably still end up doing some cases by hand though.
Consider double->int conversion, where Java has explicit NaN/Inf rules
not (afaik) shared by other languages.  Writing out the trees
explicitly will tend to confuse or overly complicate the bytecode
generator, but doing otherwise will probably yield incorrect results.
And we'd still need to handle final variables and constant string
expressions ourselves.

Tom