On Fri, Aug 30, 2019 at 12:06 PM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > 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.
The issue with GIMPLE_CONDs is that we can't have EH edges out of blocks ending in them so to represent the compare-and-jump single GIMPLE insn raising exceptions we need to split the actually trapping compare away. For [VEC_]COND_EXPR we'd need to say the whole expression can throw/trap if the embedded comparison can. On GIMPLE this is enough precision but we of course have to handle it that way then. Currently operation_could_trap* do not consider [VEC_]COND_EXPR trapping nor does tree_could_trap_p. stmt_could_throw_1_p looks fine by means of falling back to checking individual operands and then running into the embedded comparison. But we do have operation_could_trap* callers which would need to be adjusted on the GIMPLE side. Richard. > > Segher
