patch to fix

[Marc Glisse]

On Wed, 3 Oct 2012, Kenneth Zadeck wrote:

> i have already converted the vrp code, so i have some guess at where you are 
> talking about.  (of course correct me if i am wrong).
>
> in the code that computes the range when two variables are multiplied 
> together needs to do a multiplication that produces a result that is twice as 
> wide as the inputs.
>
> my library is able to do that with one catch (and this is a big catch): the 
> target has to have an integer mode that is twice as big as the mode of the 
> operands. The issue is that wide-ints actually carry around the mode of the 
> value in order to get the bitsize and precision of the operands (it does not 
> have the type, because this code has to both work on the rtl and tree level 
> and i generally do not want the signness anyway).

Ah, after reading the whole thread, now I understand that it is because 
wide_int carries a mode that it makes little sense making it a template 
(sorry that it took me so long when the information was in your first 
answer). I understand that it would be inconvenient (much longer code) to 
have a base_wide_int that does just the arithmetic and a wrapper that 
contains the mode as well.

Your idea below to define dummy extra modes does bring the template idea 
back to the table though ;-)

> my current code in vrp checks to see if such a mode exists and if it does, it 
> produces the product.   if the mode does not exist, it returns bottom.   What 
> this means is that for most (many or some) targets that have a TImode, the 
> largest thing that particular vrp discover ranges for is a DImode value.   We 
> could get around this by defining the next larger mode than what the target 
> really needs but i wonder how much mileage you are going to get out of that 
> with really large numbers.

The current wrapping multiplication code in vrp works with a pair of 
double_int, so it should keep working with a pair of wide_int. I see now 
why wide_int doesn't allow to simplify the code, but it doesn't have to 
break.

-- 
Marc Glisse