On November 26, 2015 5:36:34 PM GMT+01:00, Joseph Myers <jos...@codesourcery.com> 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 >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).
It would be easy to simply never generate any save_exprs from genmatch generated code with the effect of disabling foldings that would need it (for correctness). Richard.
