On Thu, Aug 9, 2012 at 12:25 AM, Lawrence Crowl cr...@google.com wrote:
On 8/8/12, Richard Guenther richard.guent...@gmail.com wrote:
On Aug 7, 2012 Lawrence Crowl cr...@google.com wrote:
We should probably think about naming conventions for mutating
operations, as I expect we will want them
On Thu, Aug 9, 2012 at 3:22 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Aug 9, 2012 at 12:25 AM, Lawrence Crowl cr...@google.com wrote:
On 8/8/12, Richard Guenther richard.guent...@gmail.com wrote:
On Aug 7, 2012 Lawrence Crowl cr...@google.com wrote:
We should probably
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
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 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
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_const.
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, check out
Mike Stump mikest...@comcast.net 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 Wed, Aug 8, 2012 at 9:09 AM, Miles Bader mi...@gnu.org wrote:
Mike Stump mikest...@comcast.net 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
On Tue, Aug 7, 2012 at 8:38 PM, Lawrence Crowl cr...@google.com wrote:
On 8/7/12, Richard Guenther richard.guent...@gmail.com wrote:
On Tue, Aug 7, 2012 at 2:35 AM, Lawrence Crowl cr...@google.com wrote:
Convert double_int from a struct with function into a class with
operators and methods.
Richard Guenther richard.guent...@gmail.com 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.
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
On Wed, Aug 8, 2012 at 10:33 AM, Marc Glisse marc.gli...@inria.fr 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 8/7/12, Mike Stump mikest...@comcast.net wrote:
On Aug 7, 2012, at 11:42 AM, Lawrence Crowl wrote:
On 8/7/12, Mike Stump mikest...@comcast.net 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
On 8/7/12, Richard Henderson r...@redhat.com 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_int_one;
On 8/7/12, Mike Stump mikest...@comcast.net 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
On 8/8/12, Richard Guenther richard.guent...@gmail.com wrote:
On Aug 7, 2012 Lawrence Crowl cr...@google.com 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.
On 8/8/12, Richard Guenther richard.guent...@gmail.com wrote:
On Aug 7, 2012 Lawrence Crowl cr...@google.com wrote:
On 8/7/12, Richard Guenther richard.guent...@gmail.com wrote:
For most parts overloads that take an (unsigned) HOST_WIDE_INT
argument would be nice, as well as the ability
On 8/8/12, Richard Guenther richard.guent...@gmail.com wrote:
On Aug 8, 2012 Marc Glisse marc.gli...@inria.fr 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
On 8/8/12, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Aug 8, 2012 Miles Bader mi...@gnu.org wrote:
Richard Guenther richard.guent...@gmail.com writes:
Constructors are allowed, but PODs are often passed
more efficiently. That property seemed particularly
On 8/8/12, Miles Bader mi...@gnu.org wrote:
Mike Stump mikest...@comcast.net 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 Tue, Aug 7, 2012 at 2:35 AM, Lawrence Crowl cr...@google.com 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,
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 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
On 8/7/12, Richard Guenther richard.guent...@gmail.com wrote:
On Tue, Aug 7, 2012 at 2:35 AM, Lawrence Crowl cr...@google.com 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
On 8/7/12, Mike Stump mikest...@comcast.net 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
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 are
On Aug 7, 2012, at 11:42 AM, Lawrence Crowl wrote:
On 8/7/12, Mike Stump mikest...@comcast.net 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 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 there?
r~
29 matches
Mail list logo
