This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH], Add power9 support to GCC, patch #6 (IEEE 128-bit hardware support)


I don't see any conversions between KFmode and TImode (in either 
direction, signed or unsigned) here - I suppose there are no instructions 
for that?

If so, I would guess (without having tested it) that it is more efficient 
to use the libgcc2 implementations of those functions (whether copied, or 
with some logic to build selected libgcc2.c functions for KFmode), which 
implement them using a few hardware operations on DImode [note that where 
libgcc2.c has e.g. __floatditf, that gets mapped to __floattitf for 64-bit 
systems], than to use the soft-fp implementations doing everything with 
integer arithmetic.  (There are IEEE exceptions issues with the libgcc2.c 
conversions from double-word integers to floating-point - see bug 59412 - 
but since that's a preexisting issue for all architectures using this 
code, it's clearly not your problem to fix.)

Ideally, I'd think that for optimal efficiency if objects built for power8 
are linked with libgcc built for power9, or if an executable using shared 
libgcc that was built for power8 gets run with shared libgcc for power9, 
you'd want power9 libgcc to contain t-hardfp versions of all the functions 
that can be expanded inline for power9, and libgcc2 versions of those 
(such as TImode comparisons) that aren't expanded inline, but not to 
contain soft-fp versions of any of those KFmode functions.  Cf. how 
config.host ensures various 32-bit powerpc variants use the right mixture 
of hardfp and soft-fp functions.  It's a bit fiddly to make sure you get 
the preferred implementation of every function and that the ABI doesn't 
change depending on the configured processor, but not that hard.

Since none of the libgcc pieces for KFmode support are yet in, and the 
proposed changes are optimizations rather than a matter of correctness, 
none of the above should directly affect this patch in any way - it simply 
indicates desirable followup once both the libgcc soft-fp KFmode support, 
and this patch, are in.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]