RFC: CONST_INT inconsistency fix

[Jan Hubicka <jh at suse dot cz>]

Hi,
Current handling of constants in instrucitons with mode lower than
HOST_WIDE_INT is quite inconsistent.  In some cases value is curefully
sign extended (as in simplify-rtx) to full HOST_WIDE_INT, while in others
zero extend it (as unsigned constaints in rtl generation) and rest just
keeps garbage in the upper part (such as plus_const_int).

This introduces number of headaches, one I run accross with my cmp->inc/dec
patch this week.  GCC contains a tons of tests, such as
INTVAL (const1) == INTVAL (const2) or INTVAL (const1) < 128, that are
dangerous and their result depends on the garbage present in the upper part.

One of most inportant cases are the simplifiers for comparisons, that may
result in incorrect code when different grabage appears on each side of
comparison as shown in my testcase I checked in last week.  My original
solution has been to keep track of mode comparison is done in, since it looked
like easier sollution, but this is extremly tricky in some cases and patch is
long (it is in the patches list from last month)

So my proposal is to change it, introduce function gen_trunc_int, accepting
both constant and mode and truncating it before doing GEN_INT and replace
all GEN_INT calls, that are potentially dangerous. Then we may kill the mode
parameter to simplify_comparison, if I am not mistaken, since results
will be always correct if I am not mistaken (the unsigned comparison done
on sign extended values don't change).

This will be tricky too, since at number of cases, the mode is not known and I
will need to take care to propagate it in, so it is quite bit of tedious work
so first I would like to have kind of (dis)agreement, that such sollution is
correct and worthwhile.

Comments?

Honza