[COMMITTED 0/17] - Range-op dispatch unification rework

[COMMITTED 0/17] - Range-op dispatch unification rework

[Andrew MacLeod]

This patch set completes the range-op dispatch and unification rework.

The first 7 patches move the remainder of the integral table to the 
unified table, and remove the integer table.

The 8th patch moves all the pointer specific code into a new file 
range-op-ptr.cc

Patches 9-12 introduce a "hybrid" operator class for the 4 operations 
which pointers and integer share a TREE_CODE, but have different 
implementations.  And extra hybrid class is introduced in the pointer 
file which inherits from the integer version, and adds new overloads for 
the used methods which look sa tthe type being passed in and does the 
dispatcxh itself to either the inherited integer version, or call the 
pointer version opcode.

This allows us to have a unified entry for those 4 operators 
(BIT_AND_EXPR, BIT_IOR_EXPR, MIN_EXPR, and MAX_EXPR) and move on.   WHen 
we introduce a pointer range type (ie PRANGE), we can simply add the 
prange signature to the appropriate range_operator methods, and remove 
the pointer and hybrid classes.

  patch 13 thru 16 does some tweaking to range_op_handler and hows its 
used. It now provides a default operator under the covers, so you no 
longer need to check if its valid.   The valid check now simply 
indicates if its has a custom operator implemented or not. This means 
you can simply write:

if (range_op_handler (CONVERT_EXPR).fold_range (...  ))

without worrying about whether there is an entry.  If there is no 
CONVERT_EXPR implemented, you'll simple get false back from all the calls.

Combined with the previous work, it is now always safe to call any 
range_operator routine via range_op_handler with any set of types for 
vrange parameters (including unsupported types)  on any tree code, and 
you will simply get false back if it isn't implemented.

Andrew