This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v3] Use long for mantissa for generic mp code
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 22 Mar 2013 23:29:13 +0530
- Subject: Re: [PATCH v3] Use long for mantissa for generic mp code
- References: <512D7D56 dot 2030209 at twiddle dot net> <20130308123807 dot GA21984 at spoyarek dot pnq dot redhat dot com> <5140AD70 dot 7090808 at twiddle dot net> <20130314082826 dot GT22471 at spoyarek dot pnq dot redhat dot com> <51432D0E dot 60407 at twiddle dot net> <CAAHN_R13LUMFd+YYrqj8_FRVdbsHG65ettLfQV81Uy_06ASmOQ at mail dot gmail dot com> <CAAHN_R15C_K4vabAWH863xNdZ6dRxH_rxnV+mFxWADkxmmgFRQ at mail dot gmail dot com> <514339B4 dot 1060307 at twiddle dot net> <51434720 dot 2070601 at twiddle dot net> <51434EAF dot 4090706 at twiddle dot net> <20130322092654 dot GH2409 at spoyarek dot pnq dot redhat dot com> <514C670B dot 9090301 at twiddle dot net> <CAAHN_R2wuC_87HKRnw9x99OQg_LCqSqZxG+H07_xPVG9+-yxEw at mail dot gmail dot com>
Resending for the list. My phone sends html emails and the mailer
daemon rejected it.
On 22 March 2013 23:14, Siddhesh Poyarekar <email@example.com> wrote:
> On Mar 22, 2013 7:43 PM, "Richard Henderson" <firstname.lastname@example.org> wrote:
>> On 2013-03-22 02:26, Siddhesh Poyarekar wrote:
>>> +typedef long mantissa_t;
>>> +typedef int64_t mantissa_store_t;
>> It seems like it would make sense to have mantissa_t be int32_t
>> explicitly, rather than let it be 64-bit on x86_64.
>> That'll save data space, in the mp_no structure -- we know that half the
>> data must be zeros at the moment.
> That was my initial approach but it results in additional moves from larger
> to smaller registers and vice versa which is a performance hit. The
> function is faster with everything as long.
>> More importantly, it'll make the consequences of omitting a cast to
>> mantissa_store_t be the same for the most popular testing platform as for
>> the 32-bit targets.
>> (If we could prove the no negatives property and use uint32_t, it would
>> save code size on x86_64 too. Some rex prefixes would be avoided; the
>> implicit zero-extension of all 32-bit operations would come into play,
>> avoiding the extra sign-extension insns that we will get with my int32_t
> The values themselves are always nonnegative, but there are intermediate
> values that can be negative. An example for this is in sub_magnitudes. It
> is not impossible to ensure that they are always nonnegative though. I'll
> give it a try and let you know how that works out. Would you be OK with me
> checking in this patch and work on top of it instead of reworking this