On 25.06.2024 21:07, Andrew Cooper wrote:
> In all 3 examples, we're iterating over a scaler. No caller can pass the
> COMPRESSED flag in, so the upper bound of 63, as opposed to 64, doesn't
> matter.
Not sure, maybe more a language question (for my education): Is "can"
really appropriate here? In recalculate_xstate() we calculate the
value ourselves, but in the two other cases the value is incoming to
the functions. Architecturally those value should not have bit 63 set,
but that's weaker than "can" according to my understanding. I'd be
fine with "may", for example.
> This alone produces:
>
> add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-161 (-161)
> Function old new delta
> compress_xsave_states 66 58 -8
> xstate_uncompressed_size 119 71 -48
> xstate_compressed_size 124 76 -48
> recalculate_xstate 347 290 -57
>
> where xstate_{un,}compressed_size() have practically halved in size despite
> being small before.
>
> The change in compress_xsave_states() is unexpected. The function is almost
> entirely dead code, and within what remains there's a smaller stack frame. I
> suspect it's leftovers that the optimiser couldn't fully discard.
>
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Other than the above:
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Jan
