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 jos...@codesourcery.com
