Re: fold() and target-specific macros

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > >>>>> "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.

During gimplification, perhaps?  This might work, but I'm not
*totally* convinced.  Probably.  :-)

 > 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).

That's quite right.  No, I don't believe that we should be doing much
in the way of optimization when generating bytecode.

 > 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.

Well, that is what we must consider.  Many constant folding operations
really are language and target independent, and we don't want several
implementations with disjoint sets of bugs.

Andrew.