On 5/24/23 10:20 AM, Carl Love wrote: > Extending the builtin to pre Power 9 is straight forward and I agree > would make good sense to do. > > I am a bit concerned on how to extend __builtin_set_fpscr_rn to add the > new functionality. Peter suggests overloading the builtin to either > return void or returns FPSCR bits. It is my understanding that the > return value for a given builtin had to be the same, i.e. you can't > overload the return value. Maybe you can with Bill's new > infrastructure? I recall having problems trying to overload the return > value in the past and Bill said you couldn't do it. I play with this > and see if I can overload the return value.
In this case, I don't think we need a built-in overload, but just change the current built-in to return a double rather than void. All of the old code should still work, since they'll just ignore the return value. As I said, the built-in machinery can see whether we're assigning the built-in return value to a variable or not, ie, the difference between __builtin_set_fpscr_rn (); versus: foo = __builtin_set_fpscr_rn (); In the former case, the built-in can expand exactly as how it does now. In the later case, we'll use the target rtx we're passed in as the destination of the mffscrn[i] insn for P9/10 and for pre-P9, we'll use the target for an additional mffs instruction which we don't generate now. Note we'd only generate the mffs when we're passed in a target rtx as in the second case. The first case we won't. This is all assuming Segher is fine with the change this way. If we do go this way, I would recommend adding a predefined macro that users can test for to know whether the built-in returns a value or not. If Segher doesn't like this idea, then it's all moot! :-) Peter
