[Bug tree-optimization/103253] [12 Regression] ICE: Segmentation fault (in convert_mult_to_fma or in vect_recog_mask_conversion_pattern) since r12-5129-g8ed62c929c7c4462

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 16 Nov 2021, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253
> 
> --- Comment #9 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
> > We might want to eventually special-case some of the internal fns
> > in internal_fn_flags?  Or have a special ECF_FP_TRAP which
> > we'd rewrite in internal_fn_flags based on flag_trapping_math
> > (but we'd need a caller context to be able to lookup the correct
> > flag_trapping_math here).  Alternatively whoever adds those
> > patterns should mark the GIMPLE call as gimple_call_nothrow
> > (that might be genmatch generated code in this case).
> 
> That last part seems easiest to do in this case, what's the best way
> to tell genmatch to do so for some internal-fns.  does genmatch have
> access to the ECF attributes or is it just doing symbolic rewriting?

It has access to the IL.  But then the patterns producing the
COND_MUL would need to direct genmatch to mark something nothrow
since it's not obvious to genmatch.  flag_trapping_math or
-fno-exceptions is reflected into the IL for calls so we shouldn't
really use flag_trapping_math to unconditionally make all
internal-fn calls nothrow (but that would be the simplest thing
to do of course).

So with say a transform (plus .COND_ADD .COND_ADD) to
(.COND_ADD (plus ...)) the resulting .COND_ADD should inherit
the trappingness from the existing .COND_ADD (and the plus
which does not have the flag reflected to the IL ...).
Which means we'd need to "capture" those details and annotate
result pieces.

But as said -ftrapping-math is a bit difficult because
for generic operands we just have the flag while for internal
functions it's modeled as 'throw'.  The FP exception state
is also not very well modeled.

So I think this is something for stage 1 to sort out and for
now we should simply fix the ICEs.