patch to fix constant math -5th patch, rtl
Kenneth Zadeck
zadeck@naturalbridge.com
Fri May 3 15:32:00 GMT 2013
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
More information about the Gcc-patches
mailing list