This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v3] Use long for mantissa for generic mp code

Resending for the list. My phone sends html emails and the mailer
daemon rejected it.


On 22 March 2013 23:14, Siddhesh Poyarekar <> wrote:
> On Mar 22, 2013 7:43 PM, "Richard Henderson" <> 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
>> suggestion.)
> 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
> patch?
> Siddhesh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]