From: Hans-Peter Nilsson <h...@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.