https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88558
Bug ID: 88558
Summary: Inline lrint, lrintf
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
Target Milestone: ---
Target: powerpc*-*-*
For hard-float powerpc, GCC should support inline code generation for the lrint
/ lrintf built-in functions, subject only to -fno-math-errno (the condition
-fno-math-errno is already checked in
builtins.c:expand_builtin_int_roundingfn_2, so the back end's lrint insn
patterns do not need to check that condition).
At present, the rs6000 back end has a lrint<mode>di2 pattern with an
unnecessarily restrictive TARGET_FPRND condition, that can inline llrint /
llrintf, and lrint / lrintf if long is 64-bit, for new-enough processors.
(TARGET_FPRND is supposed to be for the instructions such as frin, friz etc.;
fctiw / fctid are much older instructions). But it has nothing to generate
fctiw. (See discussions in bug 83964, where machine-specific built-in
functions for these instructions caused problems and were removed.)
At present, glibc's bits/mathinline.h for powerpc has inlines of lrint and
lrintf for 32-bit using fctiw, but we're moving away from such inlines in glibc
headers where the compiler should be able to generate appropriate code for
built-in function calls itself.
