https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373 > > --- Comment #8 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> > --- > (In reply to rguent...@suse.de from comment #7) > > On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373 > > > > > > --- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot > > > gnu.org> --- > > > FWIW, I think the reason I mentioned for skimping on this originally > > > was that we don't e.g. prevent if-conversion of: > > > > > > void > > > foo (int *c, float *f) > > > { > > > for (int i = 0; i < 16; ++i) > > > f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i]; > > > } > > > > > > for -O2 -ftree-vectorize -fno-math-errno. So it seemed like things > > > weren't very consistent. > > > > I think that's a bug in if-conversion - gimple_could_trap_p only > > says that the call instruction itself doesn't trap, it doesn't > > say anything about something in the callee body. > When's that distinction useful in practice though? It seems odd > that an FP x / y is seen as potentially trapping, but a function > call that wraps (or might wrap) an FP x / y isn't. > > > You should need -fno-trapping-math to get the above if-converted. > Is there an existing ECF flag that we can check? ECF_NOTHROW is > related but seems different enough not to be reliable. > > And is trapping a “side effect“ for the purposes of: Yes, I think trapping would be a gimple_has_side_effects effect. No, I don't think NOTRHOW covers this. On GENERIC we have TREE_THIS_NOTRAP but it's not even specified for CALL_EXPR. > /* Nonzero if this is a call to a function whose return value depends > > solely on its arguments, has no side effects, and does not read > > global memory. This corresponds to TREE_READONLY for function > > decls. */ > #define ECF_CONST (1 << 0) > > I.e. can a function still be const (on the basis that a given > argument always produces the same result) while still trapping > for some arguments? What about pure, where the trapping might > come from a memory dereference? How do we represent sNaNs with -fnon-call-exceptions? That is, y_1 = x_2 + 1.; may trap. Does foo (x_2); get transformed to tem_3 = x_2; foo (tem_3); and the SSA assignment now traps dependent on whether the call ABI requires pushing x_2 to a stack slot (which might trap)? sNaNs are odd anyway I guess. But yes, a pure function can still trap (and also throw). I think we don't have a good notion for trappingness of calls and I do expect inconsistencies here.
