[Libre-soc-dev] things we need for fast qemu

[Jacob Lifshay]

On Wed, Apr 6, 2022 at 7:15 PM lkcl <luke.leighton at gmail.com> wrote:
>
>
>
> On April 7, 2022 1:23:24 AM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> >after some time digging through qemu's git repo, i discovered that its
> >tcg
> >compiler (used for basically all emulation) has no support for
> >floating-point ops (though it apparently used to?),
>
> most likely due to incompatibilities esp on rounding modes.

actually, the rounding modes are the part where all the different cpus
agree the most...NaN encodings and propagation are where they diverge
quite a bit more.

qemu could have rounding mode be checked against what the host cpu
supports (or just against the default round-to-nearest-even with no
flushing denormals), and if it differs then it would regenerate the
code to use slower float function calls rather than native float
instructions. this would allow qemu to run many times faster using the
native float instructions.

There would also be handling for NaNs: all fp ops would act on tcg
floating-point registers. those floating-point registers would be more
like JavaScript's floats -- where there's only one conceptual NaN
(though we might need both NaN and -NaN because of the prevalence of
fp abs and neg, the rest here assumes only one NaN). conversion out of
the floating-point registers (store to memory or bitcast) would
convert the NaN value to the default NaN for the guest cpu. reading
from memory or bitcasting to produce non-default NaNs (can be tested
for pretty quickly) would cause a deoptimization trap just like
setting non-default rounding modes.

Jacob