Kewen:
On Wed, 2023-05-31 at 17:11 +0800, Kewen.Lin wrote:
> > So, there is no need for the builtin to have to determine if the
> > user
> > is storing the result of the __builtin_set_fpscr_rn. The RN bits
> > will
> > always be updated by the __builtin_set_fpscr_rn builtin and the
> > existing fields of the FPSCR will always be returned by the
> > builtin.
>
> Yeah, I agree, even with pre-P9 code when the returned value is
> unused,
> I'd expect DCE can eliminate the part for the FPSCR bits reading and
> masking, it's just like before (only setting RN bits).
>
> The only concern I mentioned before is the built-in name doesn't
> clearly
> match what it does (with extending, it returns something instead)
> since
> it's only saying "set" and setting RN bits, the return value is
> easily
> misunderstood as returning old RN bits, the documentation has to
> explain
> and note it well.
>
> Looking forward to Segher's opinion on this.
I have the patch to extend the __builtin_set_fpscr_rn builtin working.
I agree the documentation on the instructions in the ISA is not really
clear about that. It needs to be much more explicit in the builtin
description that the current RN field is returned then the field is
updated with the new RN bits from the argument.
I sent the patch, with the updated builtin description and testcases to
the GLibC team to see what they thought of it. The goal was for the
builtin to be effectively a "drop in replacement" for the inline asm
that they have. I was planning on posting the new version if the GLibC
team says it works for them. Hopefully I will hear from them soon.
Carl
