Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have random
bits.
Which is a red herring. It should be fixed. I cannot even believe
that sentence given the uses of CONST_DOUBLE_LOW/CONST_DOUBLE_HIGH
or INTVAL/UINTVAL. I don't see accesses masking out 'undefined' bits
anywhere.
Richi,
you asked for the entire patch as a branch so that you could look at the
whole picture.
It is now time for you to do that. I understand it is very large and
it will take some time for you to get your head around the whole
thing. But remember this:
The vast majority of the clients are dealing with intermediate code that
has explicit promotions. Not only the rtl level, but the majority of
the tree level takes inputs that have explicit precisions that have been
matched and wants to see an explicit precision result. For this code,
doing the fixed precision thing where you do not ever ask about what is
behind the curtain is a very good match.
However, there are parts of the compiler, all within the tree or gimple
level, that do not have this view. For this, there are two templates
export an interface that behaves in a manner very similar to what
double-int does when the precision was smaller than 128 bits. (we
discovered a large number of bugs when using double int for timode
because they did make an infinite precision assumption, but that is
another story.) All numbers are converted to signed numbers that are
extended based on their input type and the math is performed in a large
enough field so that they never push near the end. We know what the
end is because we sniff the port.
At this point we looked at the pass we were converting and we used the
appropriate implementation that match the style of coding and the
algorithm. i.e. we made no substantive changes. As mentioned in my
earlier mail, i plan to change in the future tree-ssa-ccp to use the
fixed precision form, but this is a change that is motivated by being
able to find more constants with the proper representation than what is
beautiful. But this is the only case where i think the rep should be
substantially changed.
I know you find the fixed precision stuff unappealing. But the truth
is that you wanted us to make this patch so that it did as little damage
to the way the compiler worked as possible and given that so much of the
compiler actually does fixed precision math, this is the path of least
resistance.
If it is reasonable to change the rtl, we may change that, but the truth
is that the clients never see this so it is not as much of an issue as
you are making it. Now you can see all of the clients, see this for
yourself.
Kenny
