> From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: 15 March 2013 13:06 > On Fri, Mar 15, 2013 at 08:00:50AM -0500, Gabriel Dos Reis wrote: > > 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. > > If all arguments to the target builtin constant, then it better not be > folded into REDUC_PLUS_EXPR, but instead just some constant. That is > just > fine. If all arguments to the target builtin aren't constant, then it > won't > be a constant expression anyway, there is no point in showing all those > weird tree codes to the FE.
So based on this argument, while a front-end may not need to implement all the weird tree codes it should at least have a sensible default case for an tree code which it doesn't understand. That would suggest the correct fix would be to change potential_constant_expression_1 to simply return false if it encounters a tree it doesn't know about, rather than the current gcc_unreachable (). The argument would be; if we found an unexpected tree code then it must have been introduced by folding. If it was a constant, folding would have returned the constant not the expression. So it must not be a constant. Is that be sensible? It certainly seems like someone intended to explicitly enumerate all the possible cases and ensure that they were correctly handled. I have some other patches kicking around which will fold to REDUC_MAX_EXPR, which will be another unhandled tree code. The approach of adding a case in potential_constant_expression_1 each time a shiny new tree code appears just feels wrong. James
