On 11/26/2013 07:34 AM, Richard Biener wrote:
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -98,6 +98,15 @@ along with GCC; see the file COPYING3. If not see
array CONST_VAL[i].VALUE. That is fed into substitute_and_fold for
final substitution and folding.
+ This algorithm uses wide-ints at the max precision of the target.
+ This means that, with one uninteresting exception, variables with
+ UNSIGNED types never go to VARYING because the bits above the
+ precision of the type of the variable are always zero. The
+ uninteresting case is a variable of UNSIGNED type that has the
+ maximum precision of the target. Such variables can go to VARYING,
+ but this causes no loss of infomation since these variables will
+ never be extended.
+
I don't understand this. In CCP a SSA name drops to varying when
it's not constant. How is that related to signedness or precision?!
Richi,
This is a bogosity that is inherited from the double-int code. Consider
an unsigned int in double-int (or for that matter in widest-int). It
has a rep of a bunch of leading zeros followed by 32 bits of real
stuff. Even if you know nothing about the value, it still has the
upper bits of zero that you know are constant zeros. Of course this is
not true for signed numbers because the upper bits are smeared with the
sign bits.
This was what i thought you were talking about when you argued many
months ago when you said that infinite precision was more natural and
that i would have trouble with a fixed precision based on the size of
the type or mode and is the reason that tree-ssa-ccp uses widest int
rather than wide-int. I do actually believe that wide-int is more
natural here. However this bogosity does buy you a few constants.
My first cut at this pass used wide-int rather than widest int, but
there are in fact constants that the pass finds that depend on this
being done this way so to satisfy the bit for bit same code rule for
values smaller than timode, so i left this the way that it was but
decided to document it.
The proper way to do this is in fact to use wide-int, not widest-int but
that would require major surgery to the code that converts values from
one type to another. I plan to do this during the next stage 1. At
that time, i will also enhance the code to expand the sign bit if it is
known for signed types.
Kenny
