qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH 0/6] Get rid of confusing softfloat-specific integer


From: Peter Maydell
Subject: [Qemu-devel] [PATCH 0/6] Get rid of confusing softfloat-specific integer types
Date: Tue, 12 Jan 2016 12:55:09 +0000

This patchset removes the confusing softfloat-specific integer
types int8, uint8, int32, uint32, int64 and uint64, replacing
them with the standard _t types that they were typedef'd as.
These frequently got accidentally used outside the softfloat
code as a simple typo for the standard types (as you can see
from the various files touched in the diffstat).

Although there is technically a semantic difference (the
softfloat types are "at least X bits" whereas the standard
types are "exactly X bits", the distinction is unlikely to
make much performance difference and "upgrading" the types to
use int_fast*_t would require careful code analysis to check we
weren't accidentally  relying on the type width. It also means
we might potentially have subtle bugs on only some host platforms,
which is worth avoiding I think.

(In particular glibc defines int_fast32_t as a 64 bit type
on 64 bit systems, which is unlikely to be the most sensible
type to actually use for performance. I was reading a discussion
about the _fast_ types from the musl irc channel recently:
https://gist.github.com/andrewrk/ac66b24a0a202d87cea7
which suggests that they're in practice not very useful.)

This is admittedly a different decision to the one we made in
the past for int16/uint16 (commits 94a49d86c536af3, 5aea4c589aa).
I can do a followup patch which converts our int_fast16_t/uint_fast16_t
usage to int16_t/uint16_t if people would like.
(I think the difference is partly that the old int16/uint16 types
really were bigger than 16 bits so we knew the code was not
accidentally relying on exactly-16-bitness. Also I have a feeling
that I was one of those suggesting the _fast_ types, but I have
changed my mind and think I was wrong back then.)

I have left the 'flag' type alone. This could reasonably be changed
to 'bool' if we checked all the uses to make sure they weren't
accidentally relying on it being an integer type. The type name
is not such that it will be accidentally used outside softfloat,
so it's less of an irritant.

thanks
-- PMM

Peter Maydell (6):
  fpu: Replace int64 typedef with int64_t
  fpu: Replace uint64 typedef with uint64_t
  fpu: Replace int32 typedef with int32_t
  fpu: Replace uint32 typedef with uint32_t
  fpu: Replace int8 typedef with int8_t
  fpu: Replace uint8 typedef with uint8_t

 crypto/secret.c            |   2 +-
 fpu/softfloat-macros.h     |  26 +++---
 fpu/softfloat-specialize.h |   2 +-
 fpu/softfloat.c            | 218 ++++++++++++++++++++++-----------------------
 hw/i386/pc.c               |   2 +-
 hw/ipmi/isa_ipmi_bt.c      |   2 +-
 hw/ipmi/isa_ipmi_kcs.c     |   2 +-
 hw/misc/imx25_ccm.c        |   2 +-
 hw/misc/imx31_ccm.c        |   2 +-
 hw/net/vmware_utils.h      |   2 +-
 hw/net/vmxnet3.c           |   2 +-
 hw/ppc/spapr_events.c      |   4 +-
 include/fpu/softfloat.h    |  68 ++++++--------
 include/hw/i386/pc.h       |   2 +-
 migration/ram.c            |   2 +-
 target-alpha/fpu_helper.c  |   2 +-
 target-mips/kvm.c          |   4 +-
 target-mips/msa_helper.c   |  36 ++++----
 target-s390x/kvm.c         |   2 +-
 tests/vhost-user-test.c    |   2 +-
 20 files changed, 187 insertions(+), 197 deletions(-)

-- 
1.9.1




reply via email to

[Prev in Thread] Current Thread [Next in Thread]