From: Maxim Kuvyrkov <maxim@codesourcery.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>,
Ralf Baechle <ralf@linux-mips.org>,
gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org,
rdsandiford@googlemail.com
Subject: Re: Changing the treatment of the MIPS HI and LO registers
Date: Wed, 11 Jun 2008 22:41:25 +0400 [thread overview]
Message-ID: <48501C55.5060602@codesourcery.com> (raw)
In-Reply-To: <87zlpuxqfb.fsf@firetop.home>
Richard Sandiford wrote:
...
> + <li>The MIPS port no longer recognizes the <code>h</code>
> + <code>asm</code> constraint. It was necessary to remove
> + this constraint in order to avoid generating unpredictable
> + code sequences.
> +
> + <p>One of the main uses of the <code>h</code> constraint
> + was to extract the high part of a multiplication on
> + 64-bit targets. For example:</p>
> + <pre>
> + asm ("dmultu\t%1,%2" : "=h" (result) : "r" (x), "r" (y));</pre>
> + <p>You can now achieve the same effect using 128-bit types:</p>
> + <pre>
> + typedef unsigned int uint128_t __attribute__((mode(TI)));
> + result = ((uint128_t) x * y) >> 64;</pre>
> + <p>The second sequence is better in many ways. For example,
> + if <code>x</code> and <code>y</code> are constants, the
> + compiler can perform the multiplication at compile time.
> + If <code>x</code> and <code>y</code> are not constants,
> + the compiler can schedule the runtime multiplication
> + better than it can schedule an <code>asm</code> statement.</p>
> + </li>
> </ul>
Hi,
GLIBC contains the following code in stdlib/longlong.h:
<snip>
#if defined (__mips__) && W_TYPE_SIZE == 32
#define umul_ppmm(w1, w0, u, v) \
__asm__ ("multu %2,%3" \
: "=l" ((USItype) (w0)), \
"=h" ((USItype) (w1)) \
: "d" ((USItype) (u)), \
"d" ((USItype) (v)))
#define UMUL_TIME 10
#define UDIV_TIME 100
#endif /* __mips__ */
</snip>
What would be a correct fix in this case? Something like this:
<snip>
#define umul_ppmm(w1, w0, u, v) \
({unsigned int __attribute__((mode(DI))) __xx; \
__xx = (unsigned int __attribute__((mode(DI)))) u * v; \
w0 = __xx & ((1 << 32) - 1); \
w1 = __xx >> 32;})
</snip>
Or is there a better way?
Thanks,
Maxim
next prev parent reply other threads:[~2008-06-11 18:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87tzgj4nh6.fsf@firetop.home>
[not found] ` <Pine.LNX.4.55.0805272134540.18833@cliff.in.clinika.pl>
[not found] ` <87abib4d9t.fsf@firetop.home>
[not found] ` <Pine.LNX.4.55.0805272357020.18833@cliff.in.clinika.pl>
[not found] ` <87r6bm1ebd.fsf@firetop.home>
2008-05-29 2:01 ` Changing the treatment of the MIPS HI and LO registers Maciej W. Rozycki
[not found] ` <878wxtvarg.fsf@firetop.home>
2008-06-01 13:48 ` Richard Sandiford
2008-06-09 21:13 ` Richard Sandiford
2008-06-09 21:54 ` Maciej W. Rozycki
2008-06-11 18:41 ` Maxim Kuvyrkov [this message]
2008-06-11 18:54 ` Richard Sandiford
2008-06-11 23:24 ` Paolo Bonzini
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=48501C55.5060602@codesourcery.com \
--to=maxim@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=linux-mips@linux-mips.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=rdsandiford@googlemail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.