Re: fold() and target-specific macros

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> I'm not sure what to do with this.  Perhaps we should really not be
 > Andrew> trying to do this for the Java VM, or maybe we could do something
 > Andrew> really simple like disabling target-specific folders when not actually
 > Andrew> generating target-specific code.
 > 
 > I think it is a mistake for us to use fold() in the front end.  Java
 > constant expressions are well defined by the language, platform
 > independent, and includes things that fold() doesn't do -- String
 > concatenation and using values of final variables and fields.
 > 
 > We've had to work around bad interactions between gcj and fold()
 > before; e.g., see the can_use_bit_fields_p langhook.  It seems to me
 > that continuing down this road will just give more problems in the
 > future, since first we don't know what new optimizations might be
 > added that will be incorrect for Java, and second since these things
 > are platform dependent it depends on not only better testing than we
 > seem to have, but also on more platforms.

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

 > A Java-specific folder wouldn't be hard to write, and would insulate
 > us from all this.  (FWIW this is what gcjx does, and aside from some
 > double-to-string conversion errors, easily solved with fdlibm, I think
 > it is bug-free...)

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

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

Andrew.