[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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 rguenther@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.