on 2023/5/24 06:30, Peter Bergner wrote: > On 5/23/23 12:24 AM, Kewen.Lin wrote: >> on 2023/5/23 01:31, Carl Love wrote: >>> The builtins were requested for use in GLibC. As of version 2.31 they >>> were added as inline asm. They requested a builtin so the asm could be >>> removed. >> >> So IMHO we also want the similar support for mffscrn, that is to make >> use of mffscrn and mffscrni on Power9 and later, but falls back to >> __builtin_set_fpscr_rn + mffs similar on older platforms. > > So __builtin_set_fpscr_rn everything we want (sets the RN bits) and > uses mffscrn/mffscrni on P9 and later and uses older insns on pre-P9. > The only problem is we don't return the current FPSCR bits, as the bif > is defined to return void.
Yes. > Crazy idea, but could we extend the built-in > with an overload that returns the FPSCR bits? So you agree that we should make this proposed new bif handle pre-P9 just like some other existing bifs. :) I think extending it is good and doable, but the only concern here is the bif name "__builtin_set_fpscr_rn", which matches the existing behavior (only set rounding) but doesn't match the proposed extending behavior (set rounding and get some env bits back). Maybe it's not a big deal if the documentation clarify it well. > To be honest, I like > the __builtin_set_fpscr_rn name better than __builtin_mffscrn[i]. +1 BR, Kewen > The built-in machinery can see that the usage is expecting a return value > or not and for the pre-P9 code, can skip generating the ending mffs if > we don't want the return value. > > Peter > >
