On Wed, Nov 20, 2019 at 04:59:49PM +0000, Richard Sandiford wrote: > Segher Boessenkool <seg...@kernel.crashing.org> writes: > > On Wed, Nov 20, 2019 at 05:30:48PM +0100, Jakub Jelinek wrote: > >> On Wed, Nov 20, 2019 at 10:17:38AM -0600, Segher Boessenkool wrote: > >> > On Wed, Nov 20, 2019 at 03:46:29PM +0000, Richard Sandiford wrote: > >> > > Segher Boessenkool <seg...@kernel.crashing.org> writes: > >> > > > UNLT & ORDERED is always LT. When would it not be true? > >> > > > >> > > LT traps on quiet NaNs for -ftrapping-math, UNLT and ORDERED don't. > >> > > >> > No? -ftrapping-math makes nothing trap. The only thing it does is to > >> > not do optimisations that are not valid if traps are considered to be > >> > a user-visible thing. > >> > > >> > Almost nothing ever traps on quiet NaNs. > >> > >> A lot traps even with quiet NaNs, assuming exceptions are enabled. > >> E.g. for x86 https://www.felixcloutier.com/x86/cmppd#tbl-3-1 lists the > >> details which operations rise FE_INVALID and which don't if it is enabled. > > > > That is what ordered comparisons (aka signaling comparisons) do, sure. > > This is part of "almost nothing" in my count ;-) > > > > Ordered comparisons should trap both with and without -ftrapping-math. > > The difference is that with -fno-trapping math GCC can ignore that and > > just optimise code how it wants to. > > Sure, no-one was disputing that. I think you're arguing against > a strawman here.
No, I don't understand the question I guess? Everything in that table that traps on quiet NaNs is a signaling comparison. We should simply not do simplify_logical_relational_operation for floating point types and signaling comparisons. There is no "only for some codes", etc. Segher
