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.
