qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Cc: "James Hogan" <james.hogan@imgtec.com>,
	patches@linaro.org, "Leon Alrae" <leon.alrae@imgtec.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Richard Henderson" <rth@twiddle.net>
Subject: [Qemu-devel] [PATCH 0/6] Get rid of confusing softfloat-specific integer types
Date: Tue, 12 Jan 2016 12:55:09 +0000	[thread overview]
Message-ID: <1452603315-27030-1-git-send-email-peter.maydell@linaro.org> (raw)

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	other threads:[~2016-01-12 12:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-12 12:55 Peter Maydell [this message]
2016-01-12 12:55 ` [Qemu-devel] [PATCH 1/6] fpu: Replace int64 typedef with int64_t Peter Maydell
2016-01-12 12:55 ` [Qemu-devel] [PATCH 2/6] fpu: Replace uint64 typedef with uint64_t Peter Maydell
2016-01-12 14:31   ` James Hogan
2016-01-12 17:08     ` Leon Alrae
2016-01-12 12:55 ` [Qemu-devel] [PATCH 3/6] fpu: Replace int32 typedef with int32_t Peter Maydell
2016-01-12 12:55 ` [Qemu-devel] [PATCH 4/6] fpu: Replace uint32 typedef with uint32_t Peter Maydell
2016-01-12 12:55 ` [Qemu-devel] [PATCH 5/6] fpu: Replace int8 typedef with int8_t Peter Maydell
2016-01-12 12:55 ` [Qemu-devel] [PATCH 6/6] fpu: Replace uint8 typedef with uint8_t Peter Maydell
2016-01-12 15:58 ` [Qemu-devel] [PATCH 0/6] Get rid of confusing softfloat-specific integer types Richard Henderson
2016-01-12 16:59 ` Leon Alrae
2016-01-13 15:59 ` Aurelien Jarno
2016-01-19 15:24 ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1452603315-27030-1-git-send-email-peter.maydell@linaro.org \
    --to=peter.maydell@linaro.org \
    --cc=afaerber@suse.de \
    --cc=aurelien@aurel32.net \
    --cc=james.hogan@imgtec.com \
    --cc=leon.alrae@imgtec.com \
    --cc=patches@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).