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
