On Thu, Nov 26, 2015 at 04:36:34PM +0000, Joseph Myers wrote:
> On Thu, 26 Nov 2015, Marek Polacek wrote:
>
> > My worry was of course C_MAYBE_CONST_EXPR_PRE. But it seems we'll never
> > have
> > any at that point, since it's already been processed and transformed to a
> > COMPOUND_EXPR. But do I like this patch? No.
>
> It's not obvious to me that it will always have been transformed - if a
> C_MAYBE_CONST_EXPR has escaped to gimplification, why shouldn't it be one
> with C_MAYBE_CONST_EXPR_PRE?
>
> Also, on further consideration: the folding via c_fully_fold is relied
> upon to get information about whether an expression contains anything that
> cannot occur in an evaluated part of a constant expression / outside
> sizeof in a constant expression in C90 mode. So if a SAVE_EXPR is created
> by language-independent code, c_fully_fold doesn't see inside it and you
> lose that information. What that says to me is that maybe a better
> interim solution would be a lang hook for the folders to use to call
> c_save_expr instead of save_expr. And then longer term: (a) maybe any
> folding that involves duplicating expressions and so needs to create
But the condition whether to call c_save_expr or whether to call save_expr
instead is not constant in the C FE.
If c_fully_fold is expected to be called on the expression, then c_save_expr
needs to be used, otherwise save_expr.
Can we rely on in_late_binary_op for that?
> SAVE_EXPRs would better be done only at the GIMPLE level, and (b) folding
> for conversions should be delayed as much as possible like other folding
> (and optimizations of conversions should move from convert.c to match.pd).
Jakub
