This is a series of patches making ranger type agnostic in preparation
for contributing support for other types of ranges (pointers and
floats initially).

The first step in this process is to implement vrange, an abstract
class that will be exclusively used by ranger, and from which all
ranges will inherit.  Vrange provides the minimum operations for
ranger to work.  The current virtual methods are what we've used to
implement frange (floats) and prange (pointers), but we may restrict
the virtual methods further as other ranges come about
(i.e. set_nonnegative() has no meaning for a future string range).

This patchset also provides a mechanism for declaring local type
agnostic ranges that can transparently hold an irange, frange,
prange's, etc, and a dispatch mechanism for range-ops to work with
various range types.  More details in the relevant patches.

FUTURE PLAN
===========

The plan after this is to contribute a bare bones implementation for
floats (frange) that will provide relationals, followed by a
separation of integers and pointers (irange and prange).  Once this is
in place, we can further enhance both floats and pointers.  For
example, pointer tracking, pointer plus optimizations, and keeping
track of NaN's, etc.

Once frange and prange come live, all ranger clients will immediately
benefit from these enhancements.  For instance, in our local branch,
the threader is already float aware with regards to relationals.

We expect to wait a few weeks before starting to contribute further
enhancements to give the tree a time to stabilize, and Andrew time to
rebase his upcoming patches  :-P.

NOTES
=====

In discussions with Andrew, it has become clear that with vrange
coming about, supports_type_p() is somewhat ambiguous.  Prior to
vrange it has been used to (a) determine if a type is supported by
ranger, (b) as a short-cut for checking if a type is pointer or integer,
as well as (c) to see if a given range can hold a type.  These things
have had the same meaning in irange, but are slightly different with
vrange.  I will address this in a follow-up patch.

Speaking of supported types, we now provide an unsupported_range
for passing around ranges for unsupported types. We've been silently
doing this for a while, in both vr-values by creating VARYING for
unsupported types with error_mark_node end points, and in ranger when
we pass an unsupported range before we realize in range_of_expr that
it's unsupported.  This class just formalizes what we've already been
doing in an irange, but making it explicit that you can't do anything
with these ranges except pass them.  Any other operation traps.

There is no GTY support for vrange yet, as we don't store it long
term.  When we contribute support for global ranges (think
SSA_NAME_RANGE_INFO but for generic ranges), we will include it.  There
was just no need to pollute this patchset with it.

TESTING
=======

The patchset has been tested on x86-64 Linux as well as ppc64 Linux.
I have also verified that we fold the same number of conditionals in
evrp as well as thread the same number of paths.  There should be no
user visible changes.

We have also benchmarked the work, with the final numbers being an
*improvement* of 1.92% for evrp, and 0.82% for VRP.  Overall
compilation has a miniscule improvement.  This is despite the extra
indirection level.

The improvements are mostly because of small cleanups required for the
generalization of ranges.  As a sanity check, I stuck kcachegrind on a
few sample .ii files to see where the time was being gained.  Most of
the gain came from gimple_range_global() being 19% faster.  This
function is called a lot, and it was constructing a legacy
value_range, then returning it by value, which the caller then had to
convert to an irange.  This is in line with other pending work:
anytime we get rid of legacy, we gain time.

I will wait a few days before committing to welcome any comments.

gcc/ChangeLog:

	* value-range-equiv.cc (value_range_equiv::set): New.
	* value-range-equiv.h (class value_range_equiv): Make set method
	virtual.
	Remove default bitmap argument from set method.
	* value-range.cc (vrange::contains_p): New.
	(vrange::singleton_p): New.
	(vrange::operator=): New.
	(vrange::operator==): New.
	(irange::fits_p): Move to .cc file.
	(irange::set_nonnegative): New.
	(unsupported_range::unsupported_range): New.
	(unsupported_range::set): New.
	(unsupported_range::type): New.
	(unsupported_range::set_undefined): New.
	(unsupported_range::set_varying): New.
	(unsupported_range::dump): New.
	(unsupported_range::union_): New.
	(unsupported_range::intersect): New.
	(unsupported_range::zero_p): New.
	(unsupported_range::nonzero_p): New.
	(unsupported_range::set_nonzero): New.
	(unsupported_range::set_zero): New.
	(unsupported_range::set_nonnegative): New.
	(unsupported_range::fits_p): New.
	(irange::set): Call irange::set_undefined.
	(irange::verify_range): Check discriminator field.
	(irange::dump): Dump [irange] marker.
	(irange::debug): Move to...
	(vrange::debug): ...here.
	(dump_value_range): Accept vrange.
	(debug): Same.
	* value-range.h (enum value_range_discriminator): New.
	(class vrange): New.
	(class unsupported_range): New.
	(struct vrange_traits): New.
	(is_a): New.
	(as_a): New.
	(class irange): Inherit from vrange.
	(dump_value_range): Adjust for vrange.
	(irange::kind): Rename to...
	(vrange::kind): ...this.
	(irange::varying_p): Rename to...
	(vrange::varying_p): ...this.
	(irange::undefined_p): Rename to...
	(vrange::undefined_p): ...this.
	(irange::irange): Set discriminator.
	(irange::union_): Convert to irange before passing to irange
	method.
	(irange::intersect): Same.
	(vrange::supports_type_p): New.
	* vr-values.cc (vr_values::extract_range_from_binary_expr): Pass
	NULL bitmap argument to value_range_equiv::set.
	(vr_values::extract_range_basic): Same.