Closed Urgau closed 5 months ago
@llvm/issue-subscribers-backend-powerpc
These are intrinsics that get lowered to SDAG nodes for which there is no default expansion or libcall. Each back end must handle them appropriately. Where does this come from? Do you have an actual use case that requires that the PowerPC back end handle these or is this just an observation?
My use case comes from trying to implement the IEEE 754-2019 minimum
and maximum
operations for the Rust standard library using the appropriate LLVM intrinsics, as we have done for min
and max
in the past.
As for specifically needing the PowerPC backend to support this, it's because rustc
does not (at least when I looked it up) and does not seem to be in the habit of supporting per-target intrinsics.
I once had a patch for minimum/maximum
on PowerPC (using type-J instruction after ISA 3.0): https://reviews.llvm.org/D83466
But I did not have an ideal test case to ensure whether the 'Java semantics' conforms minimum/maximum
of LLVM.
I really think we should implement these in a subtarget-independent way. We should emit the necessary code to do the comparison and to propagate NaN's as the semantics require. It may be slow on subtargets that don't have the instructions that just do the right thing, but it will at least work.
arm64 supports maxnum
and maximum
natively (fmaxnm
and fmax
). I did a test on an arm64 machine, and use following C code to emit xsmaxjdp
for llvm.maximum.f64
on ppc64le, however the result shows difference from arm64's: ppc type-j max instruction keeps signaling NaNs while fmax
on arm64 always makes them quiet. LLVM langref does not mention handling for singaling NaNs in that part, so maybe that still conforms the spec.
Anyway, x86 lowers it customly, we can do it in a similar way.
@llvm/issue-subscribers-backend-arm
Author: None (Urgau)
It seems that none of these intrinsics are currently working on PowerPC:
Error output [godbolt]:
Similar to https://github.com/llvm/llvm-project/issues/53353 which was for x86_64