--- /dev/null
+++ b/gcc/range.h
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+<http://www.gnu.org/licenses/>. */
+
+#ifndef GCC_RANGE_H
+#define GCC_RANGE_H
+#define MAX_RANGES 6
+
+typedef class irange *irange_p;
+enum irange_type { RANGE_PLAIN, RANGE_INVERT };
+
+class GTY(()) irange
+{
+ private:
+ bool overflow;
+ size_t n;
Since space usage is of concern, defining the biggest member first
and using a smaller type should help as the first step. Say:
tree type;
wide_int bounds[MAX_RANGES];
unsigned char n: 7; // 127 > MAX_RANGES
bool overflow: 1 ;
There may be other tricks to play with the array although turning
it into a flexible array member will defeat the bit-field gain.
+ void prepend (wide_int x, wide_int y);
+ void append (wide_int x, wide_int y);
+ void remove (unsigned i, unsigned j);
+ void canonicalize ();
+ /* This is stupid. These two should be private, but the GTY
+ machinery can't look inside an irange. */
+ public:
+ tree type;
+ wide_int bounds[MAX_RANGES];
+
+public:
...
+ void Union (wide_int x, wide_int y);
+ bool Union (const irange &r);
+ bool Union (const irange &r1, const irange &r2);
Do we really want methods starting with capital letters?
I understand why you can't use union, but I don't think we use CamelCase
anywhere.
One way to get around the problem is to make the functions non-
members and rename them in the process:
irange& irange_union (irange &, wide_int, wide_int);
irange& irange_union (irange &, const irange &);
irange& irange_union (irange &, const irange &, const irange &);
Making them friends of class irange will let them access private
members. Returning irange& makes chaining multiple calls possible.
I think making interfaces thin and providing operations as non
member functions is also considered the preferable design these
days.
Martin
