On Fri, Aug 30, 2019 at 09:12:11AM +0200, Richard Biener wrote: > On GIMPLE there isn't a good reason to split out trapping comparisons > from [VEC_]COND_EXPR - the gimplifier does this for GIMPLE_CONDs > where it is important because we'd have no way to represent EH info > when not done. It might be a bit awkward to preserve EH across RTL > expansion though in case the [VEC_]COND_EXPR are not expanded > as a single pattern, but I'm not sure.
The *language* specifies which comparisons trap on unordered and which do not. (Hopefully it is similar for all or this is going to be a huge mess :-) ) So Gimple needs to at least keep track of this. There also are various optimisations that can be done -- two signaling comparisons with the same arguments can be folded to just one, for example -- so it seems to me you want to represent this in Gimple, never mind if you do EH for them or just a magical trap or whatever. Segher
