Richi,
I also think that it is a digression to have this discussion about
rtl.The root problem is really that Mike, Richard, and myself do not
believe that infinite precision math is the proper way to do math for
the majority of the compiler. Most of the compiler, at both the rtl
and tr
On 05/03/2013 09:02 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:45 PM, Kenneth Zadeck wrote:
On 05/03/2013 07:19 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
wrote:
On 04/
On 05/03/2013 08:53 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:37 PM, Richard Sandiford
wrote:
Richard Biener writes:
See e.g. the hoops that cselib has to jump through:
/* We need to pass down the mode of constants through the hash table
functions. For that purpose, wrap them i
On 05/03/2013 08:40 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:31 PM, Kenneth Zadeck wrote:
On 05/03/2013 08:12 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck
wrote:
On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zade
Richard Biener writes:
>> But storing the mode in the rtx is orthogonal to what Kenny is doing.
>> The mode of each rtx constant is already available in the places
>> that Kenny is changing, because we already do the work to keep track
>> of the mode separately. Being able to get the mode directl
Richard Biener writes:
>> 5) All const_ints in the .md files would need to be given a mode
>>(except for those places where const_int actually represents
>>a C++ constant, such as in attributes).
>>
>> I realise your list wasn't supposed to be exhaustive, and neither's mine :-)
>
> Now, do
On Fri, May 3, 2013 at 2:48 PM, Richard Sandiford
wrote:
> Kenneth Zadeck writes:
>> There are several problems with just dropping a mode into the already
>> existing mode field of an rtx constant.
>> 1) There may be places where the a back end is testing equality to see
>> if constants of differ
On Fri, May 3, 2013 at 2:45 PM, Kenneth Zadeck wrote:
> On 05/03/2013 07:19 AM, Richard Biener wrote:
>>
>> On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
>> wrote:
>>>
>>> Richard Biener writes:
On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
wrote:
>
> On 04/24/2013
On Fri, May 3, 2013 at 2:37 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>>> See e.g. the hoops that cselib has to jump through:
>>>
>>> /* We need to pass down the mode of constants through the hash table
>>>functions. For that purpose, wrap them in a CONST of the appropriate
>>>
Kenneth Zadeck writes:
> There are several problems with just dropping a mode into the already
> existing mode field of an rtx constant.
> 1) There may be places where the a back end is testing equality to see
> if constants of different modes are in fact the same value.
> 2) Most of the places
On 05/03/2013 07:19 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
wrote:
On 04/24/2013 09:36 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
wrote:
Ri
On Fri, May 3, 2013 at 2:31 PM, Kenneth Zadeck wrote:
> On 05/03/2013 08:12 AM, Richard Biener wrote:
>>
>> On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck
>> wrote:
>>>
>>> On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
wrote:
>
>
Richard Biener writes:
>> See e.g. the hoops that cselib has to jump through:
>>
>> /* We need to pass down the mode of constants through the hash table
>>functions. For that purpose, wrap them in a CONST of the appropriate
>>mode. */
>> static rtx
>> wrap_constant (enum machine_mode mod
On 05/03/2013 08:12 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck wrote:
On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
wrote:
On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard San
On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck wrote:
> On 05/03/2013 07:34 AM, Richard Biener wrote:
>>
>> On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
>> wrote:
>>>
>>> On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
wrote:
>>
On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
wrote:
On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
wrote:
> On 04/24/2013 11:13 AM, Richard Biener wrote:
>>
>> On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
>> wrote:
>>>
>>> Richard Biener writes:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
>
> In othe
On Wed, Apr 24, 2013 at 5:55 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
> In other words, one of the reasons wide_int ca
On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
>> wrote:
>>> On 04/24/2013 09:36 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
wrote:
>
> Richard Biener
The only changes here were account for the changes to the wide-int api.
On 04/16/2013 04:24 PM, Kenneth Zadeck wrote:
Richard, this is the first of the tree level patches so that you can
see how the wide-int changes will effect the tree level. This patch
converts builtins.c so that it does no
On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
In other words, one of the reasons wide_int can't be exactly 1:1
in practice is because it is clearing o
Richard Biener writes:
> On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
>>> wrote:
In other words, one of the reasons wide_int can't be exactly 1:1
in practice is because it is clearing out t
Richard Biener writes:
> On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
> wrote:
>> On 04/24/2013 09:36 AM, Richard Biener wrote:
>>>
>>> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
>>> wrote:
Richard Biener writes:
>
> Can we in such cases please to a preparatory patc
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
>> wrote:
>>> In other words, one of the reasons wide_int can't be exactly 1:1
>>> in practice is because it is clearing out these mistakes (GEN_INT
>>> rather
On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
wrote:
> On 04/24/2013 09:36 AM, Richard Biener wrote:
>>
>> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
>> wrote:
>>>
>>> Richard Biener writes:
Can we in such cases please to a preparatory patch and change the
CONST_INT/CONS
Richard Biener writes:
> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
> wrote:
>> In other words, one of the reasons wide_int can't be exactly 1:1
>> in practice is because it is clearing out these mistakes (GEN_INT
>> rather than gen_int_mode) and missing features (non-power-of-2 widths).
On 04/24/2013 10:42 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
Richard Biener writes:
I suppose the above should use immed_double_int_const (v, mode), too,
In practice it doesn't matter, because...
which oddly only ever truncates to mode for modes <
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> I suppose the above should use immed_double_int_const (v, mode), too,
>
> In practice it doesn't matter, because...
>
>> which oddly only ever truncates to mode for modes <= HOST_BITS_PER_WIDE_INT
>> via gen_int
On 04/24/2013 09:36 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
wrote:
Richard Biener writes:
Can we in such cases please to a preparatory patch and change the
CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
mode precision first?
I'm not sure what y
Richard Biener writes:
> I suppose the above should use immed_double_int_const (v, mode), too,
In practice it doesn't matter, because...
> which oddly only ever truncates to mode for modes <= HOST_BITS_PER_WIDE_INT
> via gen_int_mode.
...right. That's because there's not really any proper supp
On Wed, Apr 24, 2013 at 4:03 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
Can we in such cases please to a preparatory patch and change the
CONST_INT/CONST_DOUBLE paths to do an explici
Richard Biener writes:
> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> Can we in such cases please to a preparatory patch and change the
>>> CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
>>> mode precision first?
>>
>> I'm not sure what you
On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> Can we in such cases please to a preparatory patch and change the
>> CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
>> mode precision first?
>
> I'm not sure what you mean here. CONST_INT HWIs are al
Richard Biener writes:
> Can we in such cases please to a preparatory patch and change the
> CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
> mode precision first?
I'm not sure what you mean here. CONST_INT HWIs are already sign-extended
from mode precision to HWI precision. The 8-bi
On Tue, Apr 16, 2013 at 10:17 PM, Kenneth Zadeck
wrote:
> Here is a refreshed version of the rtl changes for wide-int. the only
> change from the previous versions is that the wide-int binary operations
> have been simplified to use the new wide-int binary templates.
Looking for from_rtx calls
On 04/22/2013 08:20 AM, Richard Biener wrote:
That said, a lot of my pushback is because I feel a little lonesome in this
wide-int review and don't want to lone-some decide about that (generic)
interface part as well.
yeh, now sandiford is back from vacation so there are two of us to beat
on
Richard Biener writes:
> Richard Sandiford wrote:
>>Richard Biener writes:
At the rtl level your idea does not work. rtl constants do not
>>have a mode
or type.
>>>
>>> Which is not true and does not matter. I tell you why. Quote:
>>
>>It _is_ true, as long as you read "rtl constan
Richard Sandiford wrote:
>Richard Biener writes:
>>> At the rtl level your idea does not work. rtl constants do not
>have a mode
>>> or type.
>>
>> Which is not true and does not matter. I tell you why. Quote:
>
>It _is_ true, as long as you read "rtl constants" as "rtl integer
>constants" :
Richard Biener writes:
>> At the rtl level your idea does not work. rtl constants do not have a mode
>> or type.
>
> Which is not true and does not matter. I tell you why. Quote:
It _is_ true, as long as you read "rtl constants" as "rtl integer constants" :-)
> +#if TARGET_SUPPORTS_WIDE_INT
On 04/19/2013 09:31 AM, Richard Biener wrote:
+ number of elements of the vector that are in use. When LEN *
+ HOST_BITS_PER_WIDE_INT < the precision, the value has been
+ compressed. The values of the elements of the vector greater than
+ LEN - 1. are all equal to the highest order bit
On Sun, Apr 21, 2013 at 10:54 PM, Kenneth Zadeck
wrote:
> Richard,
>
> i pulled these two frags out of your comments because i wanted to get some
> input from you on it while i addressed the other issues you raised.
>
>
>> + enum SignOp {
>> +/* Many of the math functions produce different re
Richard,
i pulled these two frags out of your comments because i wanted to get
some input from you on it while i addressed the other issues you raised.
+ enum SignOp {
+/* Many of the math functions produce different results depending
+ on if they are SIGNED or UNSIGNED. In genera
On Tue, Apr 16, 2013 at 10:07 PM, Kenneth Zadeck
wrote:
> Richard,
>
> I made major changes to wide-int along the lines you suggested. Each of the
> binary operations is now a template.
> There are 5 possible implementations of those operations, one for each of
> HWI, unsigned HWI, wide-int, rtl,
Richard, this is the first of the tree level patches so that you can see
how the wide-int changes will effect the tree level. This patch
converts builtins.c so that it does not in any way assume that tree-cst
holds two HWIs. The patch divides all math into two categories:
Things that are
On Fri, Apr 5, 2013 at 2:34 PM, Kenneth Zadeck wrote:
> Richard,
>
> There has been something that has bothered me about you proposal for the
> storage manager and i think i can now characterize that problem. Say i want
> to compute the expression
>
> (a + b) / c
>
> converting from tree values,
Richard,
There has been something that has bothered me about you proposal for the
storage manager and i think i can now characterize that problem. Say i
want to compute the expression
(a + b) / c
converting from tree values, using wide-int as the engine and then
storing the result in a tre
On Wed, Apr 3, 2013 at 6:16 PM, Kenneth Zadeck wrote:
> On 04/03/2013 09:53 AM, Richard Biener wrote:
>>
>> On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck
>> wrote:
>>>
>>> On 04/03/2013 05:17 AM, Richard Biener wrote:
>>>
In the end you will have a variable-size storage in TREE_INT_CST thus
committed as revision 197456
kenny
On 04/03/2013 08:05 AM, Richard Biener wrote:
On Wed, Apr 3, 2013 at 12:47 PM, Kenneth Zadeck
wrote:
yes, i had caught that when i merged it in with the patches that used it, is
it ok aside from that?
Yes.
Thanks,
Richard.
kenny
On 04/03/2013 05:32 AM, R
On 04/03/2013 09:53 AM, Richard Biener wrote:
On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck wrote:
On 04/03/2013 05:17 AM, Richard Biener wrote:
In the end you will have a variable-size storage in TREE_INT_CST thus
you will have at least to emit _code_ copying over meta-data and data
from th
On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck wrote:
>
> On 04/03/2013 05:17 AM, Richard Biener wrote:
>
>> In the end you will have a variable-size storage in TREE_INT_CST thus
>> you will have at least to emit _code_ copying over meta-data and data
>> from the tree representation to the wide-in
On Wed, Apr 3, 2013 at 12:47 PM, Kenneth Zadeck
wrote:
> yes, i had caught that when i merged it in with the patches that used it, is
> it ok aside from that?
Yes.
Thanks,
Richard.
> kenny
>
> On 04/03/2013 05:32 AM, Richard Biener wrote:
>>
>> On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck
>>
On 04/03/2013 05:17 AM, Richard Biener wrote:
In the end you will have a variable-size storage in TREE_INT_CST thus
you will have at least to emit _code_ copying over meta-data and data
from the tree representation to the wide-int (similar for RTX CONST_DOUBLE/INT).
I'm objecting to the amount
yes, i had caught that when i merged it in with the patches that used
it, is it ok aside from that?
kenny
On 04/03/2013 05:32 AM, Richard Biener wrote:
On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck wrote:
this time for sure.
Almost ...
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..9
On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck wrote:
> this time for sure.
Almost ...
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..92d54a3 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,35 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT b)
{
return mul_hwi (abs_
On Tue, Apr 2, 2013 at 7:35 PM, Kenneth Zadeck wrote:
> Yes, I agree that you win the challenge that it can be done.What you
> have always failed to address is why anyone would want to do this. Or how
> this would at all be desirable.But I completely agree that from a purely
> abstract po
this time for sure.
kenny
On 04/02/2013 10:54 AM, Richard Biener wrote:
On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck wrote:
Richard,
did everything that you asked here. bootstrapped and regtested on x86-64.
ok to commit?
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
Yes, I agree that you win the challenge that it can be done.What you
have always failed to address is why anyone would want to do this. Or
how this would at all be desirable.But I completely agree that from
a purely abstract point of view you can add a storage model.
Now here is why w
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
wrote:
> This patch contains a large number of the changes requested by Richi. It
> does not contain any of the changes that he requested to abstract the
> storage layer. That suggestion appears to be quite unworkable.
I of course took this clai
On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck wrote:
> Richard,
>
> did everything that you asked here. bootstrapped and regtested on x86-64.
> ok to commit?
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,33 @@ least_commo
Richard,
did everything that you asked here. bootstrapped and regtested on
x86-64. ok to commit?
kenny
On 04/02/2013 05:38 AM, Richard Biener wrote:
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
wrote:
richard,
I was able to add everything except for the checking asserts.While I
t
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
wrote:
> richard,
>
> I was able to add everything except for the checking asserts.While I
> think that this is a reasonable idea, it is difficult to add that to a
> function that is defined in hwint.h because of circular includes. I could
> mo
richard,
I was able to add everything except for the checking asserts.While I
think that this is a reasonable idea, it is difficult to add that to a
function that is defined in hwint.h because of circular includes. I
could move this another file (though this appears to be the logical
co
richard,
adding the gcc_checking_assert is going to require that i include
system.h in hwint.h which seems to cause a loop. while in principle, i
agree with the assert, this is going to be a mess.
kenny
On 03/27/2013 10:13 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:22 AM, Kenneth
committed as revision 197200.
kenny
On 03/27/2013 11:07 AM, Richard Biener wrote:
On Wed, Mar 27, 2013 at 3:23 PM, Kenneth Zadeck
wrote:
On 03/27/2013 10:18 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
wrote:
Here is the second of my wide int patches with the
committed as revision 197198
kenny
On 03/27/2013 10:19 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:37 AM, Kenneth Zadeck
wrote:
the original patch 3 was accepted and committed. These were subsequent
comments. This could likely be just checked in the next stage 1 without
approval.
On Wed, Mar 27, 2013 at 3:23 PM, Kenneth Zadeck
wrote:
>
> On 03/27/2013 10:18 AM, Richard Biener wrote:
>>
>> On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
>> wrote:
>>>
>>> Here is the second of my wide int patches with the patch rot removed.
>>>
>>> I would like to get these pre approved for
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
wrote:
> This patch contains a large number of the changes requested by Richi. It
> does not contain any of the changes that he requested to abstract the
> storage layer. That suggestion appears to be quite unworkable.
>
> I believe that the wide
On 03/27/2013 10:18 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
wrote:
Here is the second of my wide int patches with the patch rot removed.
I would like to get these pre approved for the next stage 1.
On 10/05/2012 06:48 PM, Kenneth Zadeck wrote:
This patch add
On Wed, Feb 27, 2013 at 1:37 AM, Kenneth Zadeck
wrote:
> the original patch 3 was accepted and committed. These were subsequent
> comments. This could likely be just checked in the next stage 1 without
> approval.
Ok.
Thanks,
Richard.
>
>
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
wrote:
> Here is the second of my wide int patches with the patch rot removed.
>
> I would like to get these pre approved for the next stage 1.
> On 10/05/2012 06:48 PM, Kenneth Zadeck wrote:
>>
>> This patch adds machinery to genmodes.c so that larg
On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
wrote:
> Here is the first of my wide int patches with joseph's comments and the
> patch rot removed.
>
> I would like to get these pre approved for the next stage 1.
+ int shift = HOST_BITS_PER_WIDE_INT - (prec &
(HOST_BITS_PER_WIDE_INT - 1));
the original patch 3 was accepted and committed. These were subsequent
comments. This could likely be just checked in the next stage 1
without approval.
diff --git a/gcc/combine.c b/gcc/combine.c
index acb7421..98ca4a8 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -2635,11 +2635,6 @@
Here is the second of my wide int patches with the patch rot removed.
I would like to get these pre approved for the next stage 1.
On 10/05/2012 06:48 PM, Kenneth Zadeck wrote:
This patch adds machinery to genmodes.c so that largest possible sizes
of various data structures can be determined at
Here is the first of my wide int patches with joseph's comments and the
patch rot removed.
I would like to get these pre approved for the next stage 1.
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT "h"
This may cau
On Thu, Nov 8, 2012 at 7:13 PM, Kenneth Zadeck wrote:
> I have added the proper doc. OK to commit?
Ok.
Thanks,
Richard.
> Kenny
>
>
>
> On 10/08/2012 05:06 AM, Richard Guenther wrote:
>>
>> On Sat, Oct 6, 2012 at 12:48 AM, Kenneth Zadeck
>> wrote:
>>>
>>> This patch adds machinery to genmodes
This patch is an updated version of my patch 3 with all of richard
sandiford's comments resolved.
Richi had approved it before he went on vacation.
Committed as revision 193360.
Kenny
On 10/08/2012 03:42 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
diff --git a/gcc/combine.c b/gcc/
I have added the proper doc. OK to commit?
Kenny
On 10/08/2012 05:06 AM, Richard Guenther wrote:
On Sat, Oct 6, 2012 at 12:48 AM, Kenneth Zadeck
wrote:
This patch adds machinery to genmodes.c so that largest possible sizes of
various data structures can be determined at gcc build time. The
Joseph,
Here is a revised patch with the change you asked for. There have been
no other comments. May I commit it?
Kenny
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT "h"
This may cause problems on hosts not
either way, this needs to be investigated. it could just be my bad.
On 11/01/2012 06:28 PM, Marc Glisse wrote:
On Thu, 1 Nov 2012, Kenneth Zadeck wrote:
This patch converts tree-vpn to use wide-int. In doing so it gets
rid of all restrictions that this pass currently has on the target or
so
This patch refreshes wide-int.[ch]. Most of the changes are bug fixes
that were fixed for tree-vrp.c in patch 8.
There are two significant differences:
1) There are now constructors to override the precision and bitsize that
are normally taken from the type. These are used to perform the fi
On Thu, 1 Nov 2012, Kenneth Zadeck wrote:
This patch converts tree-vpn to use wide-int. In doing so it gets rid of
all restrictions that this pass currently has on the target or source word
size.
The pass's reliance on a finite "infinite precision" representation has been
preserved. It fi
On Oct 31, 2012, at 7:05 AM, Richard Biener wrote:
> You have an artificial limit on what 'len' can be.
No. There is no limit, and nothing artificial. We take the maximum of the
needs of the target, the maximum of the front-ends and the maximum of the
mid-end and the back-end. We can drop a
On Oct 31, 2012, at 6:54 AM, Richard Biener wrote:
> I propose that no wide-int member function
> may _change_ it's len (to something larger).
We never do that, so, we already do as you wish. We construct wide ints, and
we have member functions to construct values. We need to construct values
On Oct 31, 2012, at 5:44 AM, Richard Biener wrote:
> the
> fact that len ends up being mutable is another thing I dislike about
> wide-int.
We expose len for construction only, it is non-mutating. During construction,
there is no previous value.
> If wide-ints are cheap then all ops should be
On 10/31/2012 09:30 AM, Richard Sandiford wrote:
Richard Biener writes:
But that means that wide_int has to model a P-bit operation as a
"normal" len*HOST_WIDE_INT operation and then fix up the result
after the fact, which seems unnecessarily convoluted.
It does that right now. The operation
On 10/31/2012 08:44 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:22 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
Richard Biener wri
On 10/31/2012 10:24 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 3:18 PM, Kenneth Zadeck
wrote:
On 10/31/2012 10:05 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
wrote:
On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard S
On 10/31/2012 09:54 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 2:30 PM, Richard Sandiford
wrote:
Richard Biener writes:
But that means that wide_int has to model a P-bit operation as a
"normal" len*HOST_WIDE_INT operation and then fix up the result
after the fact, which seems unnecess
On Wed, Oct 31, 2012 at 3:18 PM, Kenneth Zadeck
wrote:
>
> On 10/31/2012 10:05 AM, Richard Biener wrote:
>>
>> On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
>> wrote:
>>>
>>> On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
On 10/31/2012 10:05 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
wrote:
On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
wrote:
>
> On 10/31/2012 08:11 AM, Richard Biener wrote:
>>
>> On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
>> wrote:
>>>
>>> Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
>
> Richar
On Wed, Oct 31, 2012 at 2:30 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>>> But that means that wide_int has to model a P-bit operation as a
>>> "normal" len*HOST_WIDE_INT operation and then fix up the result
>>> after the fact, which seems unnecessarily convoluted.
>>
>> It does that
On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
Richard Biener writes:
On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
wrote:
On 10/25/2012 06:42 A
Richard Biener writes:
>> But that means that wide_int has to model a P-bit operation as a
>> "normal" len*HOST_WIDE_INT operation and then fix up the result
>> after the fact, which seems unnecessarily convoluted.
>
> It does that right now. The operations are carried out in a loop
> over len HO
On Wed, Oct 31, 2012 at 1:22 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Thu, Oct 25
Richard Biener writes:
> On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
> wrote:
>>
>> On 10
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
wrote:
>
> On 10/25/2012 06:42 AM, Richard Biener wr
Richard Biener writes:
> On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
>>> wrote:
On 10/25/2012 06:42 AM, Richard Biener wrote:
>
> On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
>> wrote:
>>>
>>> On 10/25/2012 06:42 AM, Richard Biener wrote:
On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
>
> On Oct 24, 2012, at 2:
Richard Biener writes:
> On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
> wrote:
>>
>> On 10/25/2012 06:42 AM, Richard Biener wrote:
>>>
>>> On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
On Oct 24, 2012, at 2:43 AM, Richard Biener
wrote:
>
> On Tue, Oct 23, 2012 at
1 - 100 of 157 matches
Mail list logo
