On 12.01.2023 01:02, Andrew Cooper wrote: > On 11/01/2023 1:56 pm, Jan Beulich wrote: >> The "n" input is a GFN/MFN value and hence bounded by the physical >> address bits in use on a system. The hash quality won't improve by also >> including the upper always-zero bits in the calculation. To keep things >> as compile-time-constant as they were before, use PADDR_BITS (not >> paddr_bits) for loop bounding. This reduces loop iterations from 8 to 5. >> >> While there also drop the unnecessary conversion to an array of unsigned >> char, moving the value off the stack altogether (at least with >> optimization enabled). > > I'm not sure this final bit in brackets is relevant. It wouldn't be on > the stack without optimisations either, because ABI-wise, it will be in > %rsi.
Without optimization whether an inline function is actually inlined is unclear. When it is, what register (or stack slot) an argument is in is simply unknown. When it is made an out-of-line function, a compiler may very well spill register arguments to the stack first thing, just to make all arguments (whatsoever, i.e. not just in this function) be consistently in memory. >> Signed-off-by: Jan Beulich <[email protected]> > > Reviewed-by: Andrew Cooper <[email protected]> Thanks. Jan
