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 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,
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,
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 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
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
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
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:
> 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
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
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 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
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 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
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
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 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 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
18 matches
Mail list logo
