> This looks OK to me.
I obviously didn't look carefully enough, there are a few thinkos in the
output_constructor_bitfield hunk:
- if (shift < HOST_BITS_PER_WIDE_INT
- && shift + this_time > HOST_BITS_PER_WIDE_INT)
- {
- this_time = shift + this_time -
> the fast path is not any faster. that was why we did not do it. And by
> the time you add the tests it would be slower.The thing is that on
> the inside of the so called fast path, you are still converting the tree
> to wide-int first and that conversion still is checking the rest of
> thes
On Jan 2, 2014, at 2:26 PM, Eric Botcazou wrote:
>> So, I'd like to ping the original patch and Kenny's patch to resolve the
>> issues you found. If you have any other concerns or thoughts, let us
>> know.
>
> Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
> case of
On 01/02/2014 05:26 PM, Eric Botcazou wrote:
So, I'd like to ping the original patch and Kenny's patch to resolve the
issues you found. If you have any other concerns or thoughts, let us
know.
Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
case of expand_expr_real_1
> So, I'd like to ping the original patch and Kenny's patch to resolve the
> issues you found. If you have any other concerns or thoughts, let us
> know.
Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
case of expand_expr_real_1 (and optionally add the fast path for t
So, Kenny hopefully resolved or answered your previous email, and the only
thing outstanding was the MAX_BITS_PER_UNIT. That part of the patch is now
gone (resolved in a much nicer way in another patch).
So, I'd like to ping the original patch and Kenny's patch to resolve the issues
you found.
Richard Biener writes:
> On Sat, Dec 7, 2013 at 11:28 AM, Richard Sandiford
> wrote:
>> Kenneth Zadeck writes:
+/* One could argue that GET_MODE_PRECISION (TYPE_MODE (type))
+ should always be the same as TYPE_PRECISION (type).
+ However, it is not. Since we are c
On Sat, Dec 7, 2013 at 11:28 AM, Richard Sandiford
wrote:
> Kenneth Zadeck writes:
>>> +/* One could argue that GET_MODE_PRECISION (TYPE_MODE (type))
>>> + should always be the same as TYPE_PRECISION (type).
>>> + However, it is not. Since we are converting from tree to
>>> +
Kenneth Zadeck writes:
>> +/* One could argue that GET_MODE_PRECISION (TYPE_MODE (type))
>> + should always be the same as TYPE_PRECISION (type).
>> + However, it is not. Since we are converting from tree to
>> + rtl, we have to expose this ugly truth here. */
>> +temp
On 11/27/2013 11:24 AM, Eric Botcazou wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the first half of the rtl code.
--- a/gcc/cse.c
+++ b/gcc/cs
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the half of the rtl code.
This looks OK to me.
--
Eric Botcazou
Eric,
Let me make one high level comment here and the low level comments will
be responded to when i fix the patch.
CONST_DOUBLE has two hwis in it. So in practice, you get 128 bits and
that is it.a CONST_WIDE_INT has an array of HWIs that has as many
elements as it needs to represent
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the first half of the rtl code.
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -2336,15 +2336,23 @@ hash_rtx_cb (
13 matches
Mail list logo
