From: Richard Henderson <richard.henderson@linaro.org>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"open list:RISC-V" <qemu-riscv@nongnu.org>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"qemu-discuss@nongnu.org" <qemu-discuss@nongnu.org>,
qemu-s390x <qemu-s390x@nongnu.org>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
qemu-ppc <qemu-ppc@nongnu.org>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [RFC PATCH] configure: deprecate 32 bit build hosts
Date: Wed, 2 Oct 2019 08:16:45 -0700 [thread overview]
Message-ID: <02ab8cdf-1011-2bbb-c720-731c2b68537e@linaro.org> (raw)
In-Reply-To: <20191002091037.GB607@redhat.com>
On 10/2/19 2:10 AM, Daniel P. Berrangé wrote:
>> GCC only implements int128_t for 64-bit targets.
>
> QEMU probes for that during configure and sets CONFIG_INT128
>
> If I'm reading correctly include/qemu/int128.h then provides a
> fallback type based on a struct with two int64s.
>
> This has some inconvenience though as you have to use the the (inline)
> function calls for all the basic operands and will be less efficient
> when using the fallback.
>
> Presumably this is not viable for TCG ?
A structure (for some ABIs) may be passed and returned by invisible reference.
It's not impossible (nothing's impossible), but it adds previously unnecessary
complexity to allocate that storage on the jit stack.
Actually manipulating one 128-bit value consumes 4/6 of the i386 registers,
which I can well imagine could wind up causing problems. Certainly
manipulating two values at once is out of the question. That's less of a
problem for arm and mips.
Anyway, all of the pain points go away if we assume 64-bit.
r~
next prev parent reply other threads:[~2019-10-02 15:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 23:30 [RFC PATCH] configure: deprecate 32 bit build hosts Alex Bennée
2019-09-26 7:29 ` Philippe Mathieu-Daudé
2019-09-26 7:50 ` Peter Maydell
2019-09-26 12:58 ` Daniel P. Berrangé
2019-09-26 13:46 ` Christian Borntraeger
2019-09-26 14:26 ` Thomas Huth
2019-09-26 15:27 ` Alex Bennée
2019-09-26 16:11 ` Alistair Francis
2019-09-26 19:02 ` Alex Bennée
2019-09-27 8:55 ` Gerd Hoffmann
2019-09-26 15:31 ` Alex Bennée
2019-09-26 17:11 ` Richard Henderson
2019-09-30 9:25 ` Daniel P. Berrangé
[not found] ` <87impakrky.fsf@linaro.org>
2019-09-30 10:36 ` Peter Maydell
2019-09-30 11:41 ` Peter Maydell
2019-10-01 17:56 ` Mark Cave-Ayland
2019-10-01 18:02 ` Richard Henderson
2019-10-02 9:10 ` Daniel P. Berrangé
2019-10-02 15:16 ` Richard Henderson [this message]
2019-09-26 7:55 ` Thomas Huth
2019-09-26 15:27 ` Alex Bennée
2019-09-27 10:42 ` Mark Cave-Ayland
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=02ab8cdf-1011-2bbb-c720-731c2b68537e@linaro.org \
--to=richard.henderson@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-discuss@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/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).