This is the mail archive of the
mailing list for the GCC project.
Re: wide-int branch now up for public comment and review
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Mike Stump <mikestump at comcast dot net>, Richard Sandiford <rdsandiford at googlemail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, r dot sandiford at uk dot ibm dot com
- Date: Thu, 29 Aug 2013 09:30:32 -0400
- Subject: Re: wide-int branch now up for public comment and review
- Authentication-results: sourceware.org; auth=none
- References: <520A9DCC dot 6080609 at naturalbridge dot com> <87ppt4e9hg dot fsf at talisman dot default> <87ppt2cjt1 dot fsf at talisman dot default> <DFA6DD35-3DE6-478B-B786-EE5D2E635A4D at comcast dot net> <alpine dot LNX dot 2 dot 00 dot 1308281102320 dot 20077 at zhemvz dot fhfr dot qr>
On 08/28/2013 05:08 AM, Richard Biener wrote:
you are of course welcome to do this. But there were two questions
that i never got an answer to.
On Sun, 25 Aug 2013, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford <email@example.com> wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid cross-dependencies
between wi and wide_int_ro (except for the debug routines).
It seems reasonable; I don't see anything I object to. Seems like most of the time, the code is shorter (though, you use wi, which is fairly short). It doesn't seem any more complex, though, knowing how to spell the operation wide_int:: v wi:: is confusing on the client side. I'm torn between this and the nice things that come with the patch.
(3) Removing the comparison member functions and using the static
I've love to have richi weigh in (or someone else that wants to play the
role of C++ coding expert)? I'd defer to them?
Yeah - wi::lt (a, b) is much better than a.lt (b) IMHO. It mimics how
the standard library works.
The idea behind using a namespace rather than static functions
is that it makes it easier to separate the core, tree and rtx bits.
Being able to separate core, tree and rtx bits gets a +1 in my book. I
do understand the beauty of this.
Now, if you look back in discussions I wanted a storage
abstraction anyway. Basically the interface is
int precision ();
int len ();
element_t get (unsigned);
void set (unsigned, element_t);
and wide_int is then templated like
template <class storage>
class wide_int : public storage
where RTX / tree storage classes provide read-only access to their
storage and a rvalue integer rep to its value.
You can look at my example draft implementation I posted some
months ago. But I'll gladly wiggle on the branch to make it
more like above (easy step one: don't access the wide-int members
directly but via accessor functions)
1) how does doing this help in any way. Are their clients that will
2) isn't this just going to slow wide-int down? It seems clear that
there is a real performance cost in that now there is going to be an
extra step of indirection on each access to the underlying data structures.
I will point out we have cut down on the copying by sharing the
underlying value from trees or rtl when the value is short lived. But
given that most constants only take a single hwi to represent, getting
rid of the copying seems like a very small payback for the increase in
IMO wide-int.h shouldn't know about trees and rtxes, and all routines
related to them should be in tree.h and rtl.h instead. But using
static functions means that you have to declare everything in one place.
Also, it feels odd for wide_int to be both an object and a home
of static functions that don't always operate on wide_ints, e.g. when
comparing a CONST_INT against 16.
Indeed - in my sample the wide-int-rtx-storage and wide-int-tree-storage
storage models were declared in rtl.h and tree.h and wide-int.h did
know nothing about them.
this could be done for us too, it has nothing to do with the storage model.
Yes, though, does wi feel odd being a home for comparing a CONST_INT and
I realise I'm probably not being helpful here.
Iterating on how we want to code to look like is reasonable. Prettying
it up where it needs it, is good.
Indeed, if the code is as you like, and as richi likes, we'll then our
mission is just about complete. :-) For this patch, I'd love to defer
to richi (or someone that has a stronger opinion than I do) to say,
The comparisons? Better.
richard s is making these static.