On Mon, 7 Oct 2024, Jakub Jelinek wrote:
> On Mon, Oct 07, 2024 at 08:59:56AM +0200, Richard Biener wrote:
> > The forwprop added optmization looks like it would match PHI-opt better,
> > but I'm fine with leaving it in forwprop. I do wonder whether instead
> > of adding a flag adding the actual values wanted as argument to
> > .SPACESHIP would allow further optimizations (maybe also indicating
> > cases "ignored")? Are those -1, 0, 1, 2 standard mandated values
> > or implementation defined (or part of the platform ABI)?
>
> They are implementation defined, -1, 0, 1, 2 is defined by libstdc++:
> using type = signed char;
> enum class _Ord : type { equivalent = 0, less = -1, greater = 1 };
> enum class _Ncmp : type { _Unordered = 2 };
> https://eel.is/c++draft/cmp#categories.pre-1 documents them as
> enum class ord { equal = 0, equivalent = equal, less = -1, greater = 1 }; //
> exposition only
> enum class ncmp { unordered = -127 }; //
> exposition only
> and now looking at it, LLVM's libc++ takes that literally and uses
> -1, 0, 1, -127. One can't use <=> operator without including <compare>
> which provides the enums, so I think if all we care about is libstdc++,
> then just hardcoding -1, 0, 1, 2 is fine, if we want to also optimize
> libc++ when used with gcc, we could support -1, 0, 1, -127 as another
> option.
> Supporting arbitrary 4 values doesn't make sense, at least on x86 the
> only reason to do the conversion to int in an optab is a good sequence
> to turn the flag comparisons to -1, 0, 1. So, either we do nothing
> more than the patch, or add handle both 2 and -127 for unordered,
> or add support for arbitrary value for the unordered case except
> -1, 0, 1 (then -1 could mean signed int, 1 unsigned int, 0 do the jumps
> and any other value what should be returned for unordered.
I see.
Thanks for the clarification. The patch OK still holds.
Richard.
