Comment 93 for bug 1921664

On 'evidence that it does not significantly reduce performance'.

This will be more theoretical, as all systems that I
have access to test the changes are VMs themselves,
and didn't run QEMU with KVM acceleration enabled.

(I'm happy to be proven wrong or get contrary opinions.)

I would think the performance differences from LTO
disabled should not significantly affect performance.

The main reason is, such optimizations (or lack of)
affect QEMU code, which is somewhat bypassed on
most performance-related scenarios / hot paths.
Some examples that come to mind:
- kvm
- vhost
- vfio

Now, on the cases that such bypasses are not used,
I'd hazard to guess that, being I/O path, the CPU
instruction/optimization gains are lower magnitude
/less observable when compared to I/O delays.

The CPU optimization gains would be most noticeable
on CPU-bound paths, but in that case, the workload
is likely running qemu with KVM, in which the qemu
code is ideally not running as much as the workload.

And for CPU cases on non-KVM (ie, TCG) then performance
is not the point in general (e.g., usually enablement
or cross-arch testing, in which no native instruction
performnance is expected/required).

Again, this is more theoretical and hopefully educated
guesses; other feedback is welcome.

Perhaps if someone has access to bare-metal arm64,
ppc64el, s390x (or as possible), we could get some
tests/numbers -- but these are always workload and
qemu-config specific, so might not catch regressions
on some functionality/area.