On 12/16/2013 01:37 PM, Richard Biener wrote:
Kenneth Zadeck wrote:
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck wrote:
On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck
Kenneth Zadeck wrote:
>On 12/16/2013 09:37 AM, Richard Biener wrote:
>> Kenneth Zadeck wrote:
>>> On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
> On 12/15/2013 11:40 AM, Richard Sandiford wrote:
>> Kenneth Zadeck writes:
>>> it is certa
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck wrote:
On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
it is certainly true that in order to do an unbounded set of
Kenneth Zadeck wrote:
>On 12/16/2013 06:19 AM, Richard Biener wrote:
>> On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
>>> On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
> it is certainly true that in order to do an unbounded set of
>operations,
> you would have
On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
it is certainly true that in order to do an unbounded set of operations,
you would have to check on every operation. so my suggest
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
>
> On 12/15/2013 11:40 AM, Richard Sandiford wrote:
>> Kenneth Zadeck writes:
>>> it is certainly true that in order to do an unbounded set of operations,
>>> you would have to check on every operation. so my suggestion that we
>>> should remove the c
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
it is certainly true that in order to do an unbounded set of operations,
you would have to check on every operation. so my suggestion that we
should remove the checking from the infinite precision would not support
this.
Kenneth Zadeck writes:
> it is certainly true that in order to do an unbounded set of operations,
> you would have to check on every operation. so my suggestion that we
> should remove the checking from the infinite precision would not support
> this. but the reality is that there are cur
On 12/15/2013 03:54 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
The current world
is actually structured so that we never ask about overflow for the two
larger classes because the reason that you used those classes was that
you never wanted to have this discussion. So if you never ask
Kenneth Zadeck writes:
>>> + vallen = canonize (val, (uvlen + 1) >> 1, prec);
>>> +
>>> + /* Shift is not always safe to write over one of the
>>> +operands, so we must copy. */
>>> + HOST_WIDE_INT tval[2 * WIDE_INT_MAX_ELTS];
>>> + memcpy (tval, val, vallen * CHAR_BIT / H
Kenneth Zadeck writes:
>>> The current world
>>> is actually structured so that we never ask about overflow for the two
>>> larger classes because the reason that you used those classes was that
>>> you never wanted to have this discussion. So if you never ask about
>>> overflow, then it really do
+ vallen = canonize (val, (uvlen + 1) >> 1, prec);
+
+ /* Shift is not always safe to write over one of the
+operands, so we must copy. */
+ HOST_WIDE_INT tval[2 * WIDE_INT_MAX_ELTS];
+ memcpy (tval, val, vallen * CHAR_BIT / HOST_BITS_PER_WIDE_INT);
vallen * size
On 12/14/2013 09:30 AM, Richard Sandiford wrote:
+ /* True if the result needs to be negated. */
+ bool is_neg = false;
/* If the top level routine did not really pass in an overflow, then
just make sure that we never attempt to set it. */
bool needs_overflow = (overfl
The current world
is actually structured so that we never ask about overflow for the two
larger classes because the reason that you used those classes was that
you never wanted to have this discussion. So if you never ask about
overflow, then it really does not matter because we are not going to
Kenneth Zadeck writes:
> On 12/14/2013 06:40 AM, Richard Sandiford wrote:
>> Hi Kenny,
>>
>> Sorry for the slow response.
>>
>> Kenneth Zadeck writes:
>>> Index: gcc/wide-int.cc
>>> ===
>>> --- gcc/wide-int.cc (revision 205765)
>>> +
On 12/14/2013 06:40 AM, Richard Sandiford wrote:
Hi Kenny,
Sorry for the slow response.
Kenneth Zadeck writes:
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc (revision 205765)
+++ gcc/wide-int.cc (working copy)
@@ -1275,
Hi Kenny,
Sorry for the slow response.
Kenneth Zadeck writes:
> Index: gcc/wide-int.cc
> ===
> --- gcc/wide-int.cc (revision 205765)
> +++ gcc/wide-int.cc (working copy)
> @@ -1275,23 +1275,31 @@ wi::mul_internal (HOST_WIDE_INT
This patch is the last performance patch that i have for wide-int.
This patch changes large multiply from taking precision/hbpwi *
precision/hbpwi multiplies to taking
#significant_bits1/hbpwi * #significant_bits2/hbpwi multiplications.
That was a significant number of multiplies on machines
18 matches
Mail list logo
