Re: [RFC] fold Reorganization Plan

[Mark Mitchell <mark at codesourcery dot com>]

I agree with Nathan.  I'm going to try to restate.

Premises:

1. Exactly what expressions need to get folded at compile-time is 
language-dependent.  Therefore, front ends need to control what 
expressions get folded and how that folding takes place.

2. It is of course useful to share optimization technology across 
languages.  Constant-folding, reassociation, and other transformations 
made by "fold" are optimizations, and, therefore, we want to share them. 
 So, there's no question that this functionality should be shared.

3. The transformations done by fold are also useful in more global 
settings; the compiler should be able to fold arithmetic involving 
constants whether the constants occur in a single expression, or in 
separate basic blocks.

Conclusion:

1. Front ends should build up trees, calling fold only when/if they 
want.  For example, in C++, we would want to call fold when we finish 
processing an "integral constant expression", which is a term of art in 
C++.  (Though that operation would be recursive, that doesn't say 
anything about whether or not the code in fold.c must be recursive.  The 
C++ front end can always handle the recursion itself, if it so desires.) 
 The C++ front end probably should *not* call fold in any other 
circumstance.

2. Then, the gimplifier should perform whatever transformations are 
required by the middle end, like eliminating double NEGATE_EXPRs.

3. Kazu's proposal doesn't get in the way of this plan.  All he's doing 
is making a change that will reduce memory usage, without making major 
changes to the existing interface.  I think the key obstacle to the plan 
expressed here is not fold, but rather than the gimplifier doesn't do 
the transformations required.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304