Re: [PATCH] Add VIS intrinsics header for sparc.

[David Miller <davem at davemloft dot net>]

From: Hans-Peter Nilsson <hp@bitrange.com>
Date: Sat, 24 Sep 2011 18:37:33 -0400 (EDT)

> BTW, don't forget to clobber GSR at call insns!

This I explicitly want to avoid and is an explicit design decision.

Like I said the model is like setting the floating point rounding mode
for a family of functions.

You set the floating point rounding mode at the top level, run your
kernel and all the helper functions in that mode.

The %gsr scaling factor is to be used similarly.

You have to control all the functions that get called once you set the
%gsr before a calculation, and they either have to explicitly save and
restore the %gsr around changes to %gsr, or have been designed to use
the %gsr setting made by the callee.

The last thing I want to do is have to teach reload how to handle this
thing, it simply makes no sense to put that much engineering into it
if it is for zero or very little gain.

And it would explicitly prevent the kind of model I see as the most
reasonable for using this register, in that if we clobber it during
a call there is no way for the user to say not to save and restore
%gsr over a call.

>> So on the first set I'd have to read it, mask it out, then set the
>> scale bits.  A needless waste of 20 to 30 cycles on UltraSPARC-III.
> 
> No, it doesn't have to be read.  If the fields have (useful)
> implicit initial values (like scale=7 and align=4) at the
> beginning of any function, you wouldn't have to read and mask,
> just set.

You can't just set.  What about the VIS-2.0 byte-mask at the top
32-bits of the register, are you just going to clobber that when you
change the scale factor?

If we support treating the different fields as different registers we
have to preserve the setting of the other fields of %gsr when we
change one of them.  There are 5 fields currently defined:

1) align address <2:0>
2) scale factor <7:3>
3) interval rounding mode (VIS 2.0) <26:25>
4) interval mode enable <27>
5) Byte mask (VIS 2.0) <63:32>

And also this idea of using get_hard_reg_initial_val() to "optimize"
this kind of usage especially forces us to clobber the %gsr over
function calls which, as stated, I want to avoid if at all possible.

>> Again, this doesn't allow the user to say "don't care" about the other
>> fields like a plain "__vis_write_gsr(2<<3)" call does.
> 
> But that'd set GSR.alignaddr_offset to 0 rather than "don't
> care".

Zero is equivalent to "don't care" in this situation if either
1) you aren't doing any falignaddr operations or 2) you are
then going to subsequently do an "alignaddr" to set that field
up.

Look at the medialib code, that's basically the usage model there
and I think it's quite reasonable.

> It doesn't add hurdles for a revisit, if the mechanism is found
> unusable or the generated code pessimal!

Absolutely, thanks for your review.