t...@gmplib.org (Torbjörn Granlund) writes:
A crude test generator:
A slightly better variant. It expects an argument, either "add" or
"sub", allowing it to test both add_ss and sub_ddmmss.
This version should work fine on 32-bit systems without modification.
This code is not well-define
ni...@lysator.liu.se (Niels Möller) writes:
Do you agree?
I agree.
The excluded case,
sub_ddmmss(ah, al, bh, /*compile time constant*/0)
could clearly be optimized, in a different way, but I'd guess it's rare
enough in real code to not be worth the effort?
Clearly, longlong.h was
Dear Torbjörn,
> A crude test generator: [...]
great! On gcc115 it fails with the longlong.h shipped with GMP 6.2.0:
zimmerma@gcc115:/tmp/gmp-6.2.0$ /opt/cfarm/gcc-latest/bin/gcc test.c
zimmerma@gcc115:/tmp/gmp-6.2.0$ ./a.out > test1.c
zimmerma@gcc115:/tmp/gmp-6.2.0$ /opt/cfarm/gcc-latest
Vincent Lefevre writes:
Note: in the tests, it is important to test the macro on constants
in order to test the "if" case.
A crude test generator:
#include
#include
#include "gmp-impl.h"
void
one (size_t ind, mp_limb_t m0, mp_limb_t s0)
{
printf ("void f%zu(mp_limb_t* r1p, mp_limb_t* r
Dear Niels,
> Sorry for being unclear, sub_ddmmss has six arguments, and the case I
> wanted to single out was
>
>sub_ddmmss(rh, rl, ah, al, bh, /*compile time constant*/0)
>
> > in MPFR we have 15 places where we call sub_ddmmss, among which 8 have bl=0:
>
> Those seem to have al =
Paul Zimmermann writes:
>Dear Niels,
>
>> The excluded case,
>>
>> sub_ddmmss(ah, al, bh, /*compile time constant*/0)
>>
>> could clearly be optimized, in a different way, but I'd guess it's rare
>> enough in real code to not be worth the effort?
Sorry for being unclear, sub_ddmmss
Dear Niels,
> The excluded case,
>
> sub_ddmmss(ah, al, bh, /*compile time constant*/0)
>
> could clearly be optimized, in a different way, but I'd guess it's rare
> enough in real code to not be worth the effort?
in MPFR we have 15 places where we call sub_ddmmss, among which 8 have
t...@gmplib.org (Torbjörn Granlund) writes:
> Using the ARM "subs rd,rm,imm12" instruction, we compute
>
> {cout, rd} = rm + ~imm + 1
>
> while the "adds rd,rm,imm12" instruction, we compute
>
> {cout, rd} = rm + imm
>
> . which is quite different. The former will for example always set
ni...@lysator.liu.se (Niels Möller) writes:
And, which I guess is more relevant in the sub_ddmmss context, it also
means that there's little need for separate instructions for adding and
subtracting constants.
The error we struck here for ARM and (one of the errors) for PPC was
that we adde
t...@gmplib.org (Torbjörn Granlund) writes:
> > {cout, r} = a + ~b + cin
>
> This is a - b - borrow, where the borrow is the complement of the
> carry bit.
>
> Niels' definition is important as it captures the similarity with
> addition. It is indeed how the instructions are described in
Vincent Lefevre writes:
On 2020-06-17 11:04:26 +0200, Niels Möller wrote:
> t...@gmplib.org (Torbjörn Granlund) writes:
>
> > The two - signs ought to be ~, I think. Let me think a buit more about
that.
>
> If I remember ARM conventions correctly, subtract with carry is defined
On 2020-06-17 11:04:26 +0200, Niels Möller wrote:
> t...@gmplib.org (Torbjörn Granlund) writes:
>
> > The two - signs ought to be ~, I think. Let me think a buit more about
> > that.
>
> If I remember ARM conventions correctly, subtract with carry is defined
> as
>
> {cout, r} = a + ~b + cin
ni...@lysator.liu.se (Niels Möller) writes:
t...@gmplib.org (Torbjörn Granlund) writes:
> The two - signs ought to be ~, I think. Let me think a buit more about
that.
If I remember ARM conventions correctly, subtract with carry is defined
as
{cout, r} = a + ~b + cin
Here we trade
t...@gmplib.org (Torbjörn Granlund) writes:
> The two - signs ought to be ~, I think. Let me think a buit more about that.
If I remember ARM conventions correctly, subtract with carry is defined
as
{cout, r} = a + ~b + cin
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred.
Dear Torbjörn,
> This bug comes untimely for me. I consider a major purge along the
> lines of the patch below. [...]
I confirm all MPFR 4.1.0-rc1 tests pass on gcc115 with this patch applied to
mpfr-longlong.h, both with GCC 9.1.0 and 10.1.0 (they failed with GCC 9.1.0),
where mpfr-longl
Vincent Lefevre writes:
Note: in the tests, it is important to test the macro on constants
in order to test the "if" case.
Indeed, and one macro expansion per trivial function or else gcc might
get the idea cse constants.
This bug comes untimely for me. I consider a major purge along the
l
On 2020-06-16 16:11:53 +0200, Vincent Lefevre wrote:
> Note that I'm rather surprised to see that the issue disappears
> if I add unrelated code. For instance, in the following testcase,
> with GCC 9.1.0 -O2, I get "h = 0x", which is
> incorrect, but if I define V, I get the correct
On 2020-06-16 14:47:23 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre writes:
>
> On 2020-06-16 13:40:14 +0200, Torbjorn Granlund wrote:
> > Vincent Lefevre writes:
> >
> > #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
> > do {
Vincent Lefevre writes:
On 2020-06-16 13:40:14 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre writes:
>
> #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
> do { \
> if (__builtin_constant_p (bl) && -(UDItyp
On 2020-06-16 13:40:14 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre writes:
>
> #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
> do { \
> if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
>
Vincent Lefevre writes:
#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
do { \
if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
__asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3"
On 2020-06-16 12:55:07 +0200, Vincent Lefevre wrote:
> In longlong.h from GMP 6.2.0:
>
> #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
> do { \
> if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
> __as
Hi,
In longlong.h from GMP 6.2.0:
#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
do { \
if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
__asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3"
23 matches
Mail list logo