On Fri, Mar 15, 2013 at 3:51 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Thu, Mar 14, 2013 at 10:08 PM, Marc Glisse <marc.gli...@inria.fr> wrote: >> On Thu, 14 Mar 2013, Jakub Jelinek wrote: >> >>> I wonder if it wouldn't be better to fold the target builtins only later >>> on >>> (e.g. guard the folding with cfun && gimple_in_ssa_p (cfun) (or if we have >>> any predicate that is set starting with gimplification or so)). >>> Having all the FEs have to deal with myriads of weird tree codes etc. >>> isn't >>> IMHO desirable. >> >> >> Wouldn't that prevent from using those builtins in constant expressions? >> That seems undesirable. Maybe an alternative could be to push some of the >> functionality from potential_constant_expression_1 to the middle-end? > > True, but is that bad? > > If we want to delay such folding then please don't do it with a magic flag > but instead do the folding only via fold_stmt - that is, add a new target hook > that folds a gimple call. I bet we have only a very limited set of target > call > foldings, so transitioning them all to fold gimple calls would be easy.
upon reflection, I think we don't want to delay. the C++ front-end needs to know (while type checking) whether a certain operation can be evaluated at compile time and possibly get the value of the operation. -- Gaby
