From: Al Viro <viro@ZenIV.linux.org.uk>
To: Richard Henderson <rth@twiddle.net>
Cc: Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
Date: Thu, 3 Jul 2014 07:51:04 +0100 [thread overview]
Message-ID: <20140703065104.GP18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20140702152027.GN18016@ZenIV.linux.org.uk>
More bugs: addl/v should sign-extend the result, as addl does.
As it is, we have
uint64_t helper_addlv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
{
uint64_t tmp = op1;
op1 = (uint32_t)(op1 + op2);
if (unlikely((tmp ^ op2 ^ (-1UL)) & (tmp ^ op1) & (1UL << 31))) {
arith_excp(env, GETPC(), EXC_M_IOV, 0);
}
return op1;
}
IOW,
#include <stdio.h>
long r;
void __attribute__((noinline)) f(void)
{
asm __volatile(
"subl $31, 1, $0\n\t"
"addl $0, $0, $1\n\t"
"addl/v $0, $0, $0\n\t"
"subq $0, $1, $0\n\t"
"stq $0, %0\n\t"
: "=m"(r): :"$0", "$1");
}
main()
{
f();
printf("%ld\n", r);
}
ends up printing 0 on actual hardware (all variants) and 4294967296 on
qemu. Similar problem with subl/v -
#include <stdio.h>
long r;
void __attribute__((noinline)) f(void)
{
asm __volatile(
"subl $31, 1, $0\n\t"
"subl/v $31, 1, $1\n\t"
"subq $0, $1, $0\n\t"
"stq $0, %0\n\t"
: "=m"(r): :"$0", "$1");
}
main()
{
f();
printf("%ld\n", r);
}
prints 0 on actual hw and -4294967296 on qemu. What constraints do we have
on qemu host, anyway? Two's-complement, (int32_t)(uint32_t)x == x for any
int32_t x? helper_mullv() seems to assume that...
Oh, crap - our mull/v is sensitive to upper 32 bits of multiplicands.
If you put 1UL<<32 into one register, 1 into another and say mull/v,
result will be 0 and no overflow. qemu does
int64_t res = (int64_t)op1 * (int64_t)op2;
if (unlikely((int32_t)res != res)) {
arith_excp(env, GETPC(), EXC_M_IOV, 0);
}
return (int64_t)((int32_t)res);
which leads to overflow trap triggered for no good reason...
Incidentally, all those guys ({add,sub,mul}[lq]/v) *do* assign the result
(same as the variant without /v would) before entering the trap. So
arith_excp() is wrong here.
FWIW, why not just generate
trunc_i64_i32 tmp, va
trunc_i64_i32 tmp2, vb
muls2_i32 tmp2, tmp, tmp, tmp2
ext32s_i64 vc, tmp2
maybe_overflow_32 tmp
where maybe_overflow throws IOV unless tmp is 0 or -1? That would appear
to suffice for mull/v. mulq/v would be
muls2_i64 vc, tmp, va, vb
maybe_overflow_64 tmp
addl/v:
trunc_i64_i32 tmp, va
trunc_i64_i32 tmp2, vb
add2_i32 tmp2, tmp, tmp, zero, tmp2, zero
ext32s_i64 vc, tmp2
maybe_overflow_32 tmp
etc.
We'd need two helpers, differing only in argument type. Simple
if (unlikely(arg && ~arg))
arith_excp(env, GETPC(), EXC_M_IOV, 0);
would do. Not sure what flags would be needed in DEFINE_HELPER_... for
those, though. Comments?
next prev parent reply other threads:[~2014-07-03 6:51 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 4:34 [Qemu-devel] [RFC] alpha qemu arithmetic exceptions Al Viro
2014-06-24 16:52 ` Al Viro
2014-06-24 18:33 ` Richard Henderson
2014-06-24 20:32 ` Al Viro
2014-06-24 20:57 ` Richard Henderson
2014-06-24 21:24 ` Al Viro
2014-06-24 21:32 ` Richard Henderson
2014-06-25 7:01 ` Al Viro
2014-06-25 9:27 ` Peter Maydell
2014-06-25 14:26 ` Al Viro
2014-06-25 17:41 ` Peter Maydell
2014-06-26 5:55 ` Al Viro
2014-06-30 18:39 ` Richard Henderson
2014-06-30 20:56 ` Al Viro
2014-07-01 4:34 ` Al Viro
2014-07-01 5:00 ` Al Viro
2014-07-01 14:31 ` Richard Henderson
2014-07-01 17:03 ` Richard Henderson
2014-07-01 17:50 ` Al Viro
2014-07-01 18:23 ` Peter Maydell
2014-07-01 18:30 ` Richard Henderson
2014-07-01 19:08 ` Peter Maydell
2014-07-02 4:05 ` Al Viro
2014-07-02 5:50 ` Al Viro
2014-07-02 6:17 ` Al Viro
2014-07-02 15:26 ` Richard Henderson
2014-07-02 15:49 ` Al Viro
2014-07-02 14:59 ` Richard Henderson
2014-07-02 15:20 ` Al Viro
2014-07-03 6:51 ` Al Viro [this message]
2014-07-03 18:25 ` Al Viro
2014-07-03 20:19 ` Richard Henderson
2014-07-03 22:47 ` Al Viro
2014-07-03 23:05 ` Peter Maydell
2014-07-03 23:22 ` Al Viro
2014-07-04 0:50 ` Al Viro
2014-07-04 4:30 ` Richard Henderson
2014-07-04 7:29 ` Al Viro
2014-07-05 1:40 ` Al Viro
2014-07-05 5:26 ` Al Viro
2014-07-05 21:09 ` Al Viro
2014-07-05 22:55 ` Al Viro
2014-07-07 14:11 ` Richard Henderson
2014-07-07 15:06 ` Al Viro
2014-07-07 16:20 ` Richard Henderson
2014-07-08 4:20 ` Al Viro
2014-07-08 6:03 ` Richard Henderson
2014-07-08 6:54 ` Al Viro
2014-07-08 7:13 ` Al Viro
2014-07-08 8:05 ` Peter Maydell
2014-07-08 14:53 ` Richard Henderson
2014-07-08 16:13 ` Al Viro
2014-07-08 16:33 ` Peter Maydell
2014-07-08 17:20 ` Al Viro
2014-07-08 19:32 ` Peter Maydell
2014-07-08 20:12 ` Al Viro
2014-07-09 9:19 ` Alex Bennée
2014-07-09 9:04 ` Alex Bennée
2014-07-08 18:12 ` Richard Henderson
2014-07-08 19:02 ` Al Viro
2014-07-08 19:04 ` Richard Henderson
2014-07-08 20:20 ` Al Viro
2014-07-09 4:59 ` Richard Henderson
2014-07-09 5:47 ` Al Viro
2014-07-09 15:14 ` Richard Henderson
2014-07-09 16:41 ` Al Viro
2014-06-24 18:23 ` Richard Henderson
2014-06-24 20:47 ` Al Viro
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=20140703065104.GP18016@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=peter.maydell@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).