Re: patch to fix constant math -5th patch, rtl

[Kenneth Zadeck]

Richi,

I also think that it is a digression to have this discussion about 
rtl.    The root problem is really that Mike, Richard, and myself do not 
believe that infinite precision math is the proper way to do math for 
the majority of the compiler.   Most of the compiler, at both the rtl 
and tree level just does the math inline.   There are 314 places at the 
tree level where we ask if the value fits in a hwi and then we do the 
hwi inline math.   The rtl level is even more skewed towards this style 
of programming.  While you view replacing double-int as my primary goal, 
it accounts for the minority of the places in the code where wide-int 
needs to be used.

Furthermore to call what is done in double-int infinite precision is 
really pushing it.   Because it certainly is not infinite if you happen 
to have a TImode variable.

What i did when i designed wide-int was to come up with a mechanism 
where i could preserve the performance of that inline math while 
generalizing it so that it worked correctly for any width. That is why 
the precision is there.   It allows me to avoid the hard work 99% of the 
time, with an inline test of the precision and then a branch free 
calculation of the answer.   For instance there is no loop checking for 
carries and propagating them.

I also feel strongly that it is our responsibility to preserve, to the 
extent possible, the notion that optimization never changes the output 
of a program, except of course for timing.   We, in the optimization 
community, do not always so do so well here, but at the very least, we 
should always try.   Having said that, there are optimizations like VRP 
that really do need to do math larger than precision defined in the 
type.   I get this, and always have.   I understand that if you truncate 
multiplies, add or subtracts, in VRP then the resulting range is not 
simple and becomes too difficult to reasonably represent.    I have no 
intention of giving up anything in VRP.   My plan for that is to look at 
the types used in function being compiled and take the largest type, 
double the precision, and do all of the math within VRP at that expanded 
fixed precision.   We can always guarantee that we can do this in 
wide-int since the size of the buffer is computed by looking at the 
target's modes and taking the largest one those times a comfortable 
multipler.   Since you cannot have a type without a corresponding mode, 
this will always work.   This scheme preserves the behavior of VRP while 
making it work with any sized integer.
The alternative is to use a true infinite precision package for VRP but 
i think that is overkill.

Kenny