On August 27, 2015 6:07:59 PM GMT+02:00, Kai Tietz <ktiet...@googlemail.com> wrote: >2015-08-27 12:34 GMT+02:00 Richard Biener <richard.guent...@gmail.com>: >> On Thu, Aug 27, 2015 at 11:21 AM, Kai Tietz <ktiet...@googlemail.com> >wrote: >>> 2015-08-27 4:57 GMT+02:00 Jason Merrill <ja...@redhat.com>: >>>> Why does fold_simple fold so many patterns? I thought we wanted >something >>>> that would just fold conversions and negations of constant values. >>> >>> Yes, initial variant was handling much less patterns. But actually >we >>> need for functions (eg. like build_vec_init in init.c) a simple >>> routine to perform basic constant-value arithmetics (sizeof * / + - >>> trunc, etc) to avoid call of maybe_constant_value. Also for >>> overflow-diagnostics we want at least to resolve such simple >patterns >>> for constant-values only. We could change those calls to use >>> maybe_constant_value instead, but the overhead (and some of its >>> folding) leads much further then working on constant-values only (as >>> fold_simple does). >>> >>> It might be that we can remove the ternary vector-cond expression >from >>> this routine, The cond-expr itself seems to be necessary to resolve >>> patterns like (1 == 1 ? 32 : 64), which can appear pretty often via >>> macro-code. I will check if I what patterns I can remove here. >> >> Note that fold-const.c has constant-only folding routines (handling >only >> constant operands). const_unop, const_binop (no const_ternop split >> out yet). >> >> Richard. > >Thanks for the point. I will take a look into cons_unop/binop. I >just expect that this routines would fail if they get c++-expressions, >aren't they?
They fail for everything they do not handle. Richard. >>>> Jason > >Kai
