This is the mail archive of the gcc@gcc.gnu.org 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


Andrew Haley wrote:
Mark Mitchell writes:
> > > 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.)


There's one other thing to bear in mind when considering the way that
fold relates to language front ends.  We've seen problems in Java
where fold() returned tree nodes that Java didn't recognize: one time,
for example, it returned a BITFIELD_EXPR.

Yes, that's certainly problematic.


Although I think that fold should remain in language-independent code, that is not to say that it should not necessarily be informed by langhooks as to what exactly it should do.

However, while that may be necessary for Java, it's not necessary for C++. In C++, fold should only be called for "integral constant expressions", which, by definition, are made up of simple operations on integers. (It's a little more complicated than that, but all the operands collapse to integers immediately.) So, all we really need for C++ is the ability to convert floating-point constants to integer constants, and the ability to do basic arithmetic on integer constants. I certainly hope that given those inputs, any reasonable implementation of fold will only return an integer constant. So, the plan I outlined would solve the kind of problem you describe for C++ because C++ will only call fold with these limited inputs, and therefore never see unexpected returns. The gimplifier can introduce all the weird nodes it wants, as at that point the C++ front end is out of the picture. Of course, for C++, we could -- and perhaps should -- just avoid fold altogether, and just use int_const_binop instead.

Thus, as I said earlier, from a C++ point of view, the obstacle is that failure to call fold may result in the output of the gimplifier being invalid, as Roger Sayle has indicated that the middle-end is expecting the front end to call fold before gimplification.

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


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