There are a bunch of ways to skin the cat.
1) we can define the extra mode.
2) if we get rid of the mode inside the wide int and replace it with an
explicit precision and bitsize, then we can just make the size of the
buffer twice as big as the analysis of the modes indicates.
3) or we can leave your code in a form that uses 2 wide ints. my
current patch (which i have not gotten working yet) changes this to use
the mul_full call, but it could be changed. It is much simpler that
the existing code.
i do not see how templates offer any solution at all. the wide int
code really needs to have something valid to indicate the length of the
object, and if there is no mode that big, the code will ice.
my personal feeling is that range analysis is quite useful for small
integers and not so much as the values get larger. The only really
large integer constants that you are likely to find in real code are
encryption keys, like the dvd decoding keys, and if the key is chosen
well there should be no useful optimization that you can perform on the
code. If this did not work on the largest modes, no one would ever
notice. i.e. i would bet that you never make a useful transformation
on any integer that would not fit in an int32.
However, this is your pass, and i understand the principal of "never
back down".
Kenny
On 10/04/2012 05:06 PM, Marc Glisse wrote:
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.
