This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] fold Reorganization Plan

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 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
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]