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

["rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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:

/* 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?