This is the mail archive of the gcc-patches@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: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.


On Fri, Mar 15, 2013 at 3:51 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Mar 14, 2013 at 10:08 PM, Marc Glisse <marc.glisse@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


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