On Aug 9, 2012, at 5:00 PM, Michael Matz wrote:
> On Thu, 9 Aug 2012, Mike Stump wrote:
>
>> On Aug 9, 2012, at 8:19 AM, Michael Matz wrote:
>>> Hmm. And maintaining a cache is faster than
>>> passing/returning/manipulating two registers?
>>
>> For the most part, we merely mirror existing code,
Hi,
On Thu, 9 Aug 2012, Mike Stump wrote:
> On Aug 9, 2012, at 8:19 AM, Michael Matz wrote:
> > Hmm. And maintaining a cache is faster than
> > passing/returning/manipulating two registers?
>
> For the most part, we merely mirror existing code, check out
> lookup_const_double and immed_double
On Aug 9, 2012, at 8:19 AM, Michael Matz wrote:
> Hmm. And maintaining a cache is faster than
> passing/returning/manipulating two registers?
For the most part, we merely mirror existing code, check out
lookup_const_double and immed_double_const. If the existing code is wrong,
love to have so
Hi,
On Thu, 9 Aug 2012, Mike Stump wrote:
> > Ah. For simple objects like double_int I prefer to have either all
> > ops mutating or all ops non-mutating.
>
> wide_int, which replaces double_int for int types, is always
> non-mutating, by value interface. In C++, it will be const & input
>
On Aug 9, 2012, at 1:22 AM, Richard Guenther wrote:
> Ah. For simple objects like double_int I prefer to have either all ops
> mutating
> or all ops non-mutating.
wide_int, which replaces double_int for int types, is always non-mutating, by
value interface. In C++, it will be const & input par
On Thu, Aug 9, 2012 at 3:22 AM, Richard Guenther
wrote:
> On Thu, Aug 9, 2012 at 12:25 AM, Lawrence Crowl wrote:
>> On 8/8/12, Richard Guenther wrote:
>>> On Aug 7, 2012 Lawrence Crowl wrote:
>>> > We should probably think about naming conventions for mutating
>>> > operations, as I expect we w
On Thu, Aug 9, 2012 at 12:25 AM, Lawrence Crowl wrote:
> On 8/8/12, Richard Guenther wrote:
>> On Aug 7, 2012 Lawrence Crowl wrote:
>> > We should probably think about naming conventions for mutating
>> > operations, as I expect we will want them eventually.
>>
>> Right. In the end I would pref
On Thu, Aug 9, 2012 at 12:17 AM, Lawrence Crowl wrote:
> On 8/7/12, Mike Stump wrote:
>> On Aug 7, 2012, at 11:38 AM, Lawrence Crowl wrote:
>> > Hm. There seems to be significant opinion that there should not be any
>> > implicit conversions. I am okay with operations as above, but would like
>
On 8/8/12, Miles Bader wrote:
> Mike Stump writes:
> > > Constructors are allowed, but PODs are often passed more
> > > efficiently. That property seemed particularly important
> > > for double_int.
> >
> > Show us the difference in timing. Show us the generated code.
> > I can't imagine that i
On 8/8/12, Gabriel Dos Reis wrote:
> On Aug 8, 2012 Miles Bader wrote:
> > Richard Guenther writes:
> > > > > > Constructors are allowed, but PODs are often passed
> > > > > > more efficiently. That property seemed particularly
> > > > > > important for double_int.
> > > > >
> > > > > Show us t
On 8/8/12, Richard Guenther wrote:
> On Aug 8, 2012 Marc Glisse wrote:
> > On Wed, 8 Aug 2012, Richard Guenther wrote:
> > > > > > + static double_int make (unsigned HOST_WIDE_INT cst);
> > > > > > + static double_int make (HOST_WIDE_INT cst);
> > > > > > + static double_int make (unsigned int
On 8/8/12, Richard Guenther wrote:
> On Aug 7, 2012 Lawrence Crowl wrote:
> > On 8/7/12, Richard Guenther wrote:
> > > For most parts overloads that take an (unsigned) HOST_WIDE_INT
> > > argument would be nice, as well as the ability to say dbl + 1.
> >
> > Hm. There seems to be significant op
On 8/8/12, Richard Guenther wrote:
> On Aug 7, 2012 Lawrence Crowl wrote:
> > We should probably think about naming conventions for mutating
> > operations, as I expect we will want them eventually.
>
> Right. In the end I would prefer explicit constructors.
I don't think we're thinking about t
On 8/7/12, Mike Stump wrote:
> On Aug 7, 2012, at 11:38 AM, Lawrence Crowl wrote:
> > Hm. There seems to be significant opinion that there should not be any
> > implicit conversions. I am okay with operations as above, but would like
> > to hear the opinions of others.
>
> If there is an agreed
On 8/7/12, Richard Henderson wrote:
> On 08/06/2012 05:35 PM, Lawrence Crowl wrote:
> > +inline double_int &
> > +double_int::operator ++ ()
> > +{
> > + *this + double_int_one;
> > + return *this;
> > +}
> > +
> > +inline double_int &
> > +double_int::operator -- ()
> > +{
> > + *this - double
On 8/7/12, Mike Stump wrote:
> On Aug 7, 2012, at 11:42 AM, Lawrence Crowl wrote:
> > On 8/7/12, Mike Stump wrote:
> > > On Aug 6, 2012, at 5:35 PM, Lawrence Crowl wrote:
> > > > Convert double_int from a struct with function into a class
> > > > with operators and methods.
> > >
> > > We have a
On Wed, Aug 8, 2012 at 3:29 AM, Miles Bader wrote:
> Richard Guenther writes:
> Constructors are allowed, but PODs are often passed more efficiently.
> That property seemed particularly important for double_int.
Show us the difference in timing. Show us the generated code. I
>
On Wed, Aug 8, 2012 at 10:33 AM, Marc Glisse wrote:
> On Wed, 8 Aug 2012, Richard Guenther wrote:
>
> + static double_int make (unsigned HOST_WIDE_INT cst);
> + static double_int make (HOST_WIDE_INT cst);
> + static double_int make (unsigned int cst);
> + static double_int make
On Wed, 8 Aug 2012, Richard Guenther wrote:
+ static double_int make (unsigned HOST_WIDE_INT cst);
+ static double_int make (HOST_WIDE_INT cst);
+ static double_int make (unsigned int cst);
+ static double_int make (int cst);
[...]
Btw, if HOST_WIDE_INT == int the above won't even compile.
Richard Guenther writes:
Constructors are allowed, but PODs are often passed more efficiently.
That property seemed particularly important for double_int.
>>>
>>> Show us the difference in timing. Show us the generated code. I
>>> can't imagine that it could ever matter.
>>
>> I'm also
On Tue, Aug 7, 2012 at 8:38 PM, Lawrence Crowl wrote:
> On 8/7/12, Richard Guenther wrote:
>> On Tue, Aug 7, 2012 at 2:35 AM, Lawrence Crowl wrote:
>> > Convert double_int from a struct with function into a class with
>> > operators and methods.
>> >
>> > This patch adds the methods and operator
On Wed, Aug 8, 2012 at 9:09 AM, Miles Bader wrote:
> Mike Stump writes:
>>> Constructors are allowed, but PODs are often passed more efficiently.
>>> That property seemed particularly important for double_int.
>>
>> Show us the difference in timing. Show us the generated code. I
>> can't imagin
Mike Stump writes:
>> Constructors are allowed, but PODs are often passed more efficiently.
>> That property seemed particularly important for double_int.
>
> Show us the difference in timing. Show us the generated code. I
> can't imagine that it could ever matter.
I'm also curious about that s
On 08/06/2012 05:35 PM, Lawrence Crowl wrote:
> +inline double_int &
> +double_int::operator ++ ()
> +{
> + *this + double_int_one;
> + return *this;
> +}
> +
> +inline double_int &
> +double_int::operator -- ()
> +{
> + *this - double_int_one;
> + return *this;
> +}
Surely unused results ther
On Aug 7, 2012, at 11:42 AM, Lawrence Crowl wrote:
> On 8/7/12, Mike Stump wrote:
>> On Aug 6, 2012, at 5:35 PM, Lawrence Crowl wrote:
>>> Convert double_int from a struct with function into a class with
>>> operators and methods.
>>
>> We have a wide_int class that replaces this class. :-(
>
>
On Aug 7, 2012, at 11:38 AM, Lawrence Crowl wrote:
> Hm. There seems to be significant opinion that there should not be any
> implicit conversions. I am okay with operations as above, but would like
> to hear the opinions of others.
If there is an agreed upon and expected semantic, having them a
On 8/7/12, Mike Stump wrote:
> On Aug 6, 2012, at 5:35 PM, Lawrence Crowl wrote:
>> Convert double_int from a struct with function into a class with
>> operators and methods.
>
> We have a wide_int class that replaces this class. :-(
Really? Where? I don't see neither definition nor use under
On 8/7/12, Richard Guenther wrote:
> On Tue, Aug 7, 2012 at 2:35 AM, Lawrence Crowl wrote:
> > Convert double_int from a struct with function into a class with
> > operators and methods.
> >
> > This patch adds the methods and operators. In general functions of
> > the form "double_int_whatever"
On 12-08-07 13:22 , Mike Stump wrote:
On Aug 6, 2012, at 5:35 PM, Lawrence Crowl wrote:
Convert double_int from a struct with function into a class with
operators and methods.
We have a wide_int class that replaces this class. :-( It would
have been better to just convert it. Do you guys ha
On Aug 6, 2012, at 5:35 PM, Lawrence Crowl wrote:
> Convert double_int from a struct with function into a class with
> operators and methods.
We have a wide_int class that replaces this class. :-( It would have been
better to just convert it. Do you guys have a timeframe for the cxx-conversion
On Tue, Aug 7, 2012 at 2:35 AM, Lawrence Crowl wrote:
> Convert double_int from a struct with function into a class with
> operators and methods.
>
> This patch adds the methods and operators. In general functions of
> the form "double_int_whatever" become member functions "whatever" or,
> when p
31 matches
Mail list logo
