This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] fold Reorganization Plan
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Geert Bosch <bosch at adacore dot com>
- Cc: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, gcc at gcc dot gnu dot org, roger at eyesopen dot com
- Date: Tue, 15 Feb 2005 09:29:06 -0800
- Subject: Re: [RFC] fold Reorganization Plan
- Organization: CodeSourcery, LLC
- References: <10502122058.AA25339@vlsi1.ultra.nyu.edu> <email@example.com>
I agree with Nathan. I'm going to try to restate.
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.
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
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.