This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [wide-int] Handle zero-precision INTEGER_CSTs again


Then with a fixed comment, this patch is fine.

kenny

On 05/03/2014 02:59 PM, Richard Sandiford wrote:
Kenneth Zadeck <zadeck@naturalbridge.com> writes:
The doc at wide-int.h:136 needs work.    The doc currently says that the
precision and length are always greater than 0.   This is now not
correct.     It also says that the bits above the precision are defined
to be the sign extension if the precision does not cover that block.
I agree that the comment needs work.

Reordering slightly:

I do not know if i believe this completely.
This is now covered by the compile-time is_sign_extended property.

Trees aren't extended in that way because we want to be able to access
them quickly in wider precisions, with the extension following the
signedness of the underlying type.  So an 8-bit all-ones INTEGER_CST
will be stored as -1 if the type is signed and as 0xff otherwise.

RTL constants aren't sign-extended because of the case you note:

I worry about this because we have moved back and forth on this issue
many times and i still see code at rtl.h:1440 which assumes that BImode
constants are stored differently on some platforms. It is possible that
i am reading that code incorrectly but at first reading it looks
questionable.   so code comparing a bimode 1 with a 1 of a different
precision would not work.
I hope to get rid of the special BImode case after the merge and set
rtl's is_sign_extended back to true.

wide_int itself is always sign-extended.  The situation never occurs
for offset_int and widest_int.

I noticed that in the eq_p_large code, you removed a block of code left
over from the days when this was not true, but there is still so of this
code remaining that does not assume this.
The *_large functions have to be conservative and assume that the inputs
are not sign-extended.  My eq_p_large change doesn't change that,
it just represents it differently.  The idea is that rather than
extending each HWI individually from small_prec and then comparing them,
we can shift the XOR of the two values left by the number of excess bits,
so that all undefined bits disappear from the value.  The shifted-in bits
are all zeros so the shifted XOR value will be zero iff the meaningful
bits are the same and nonzero iff the meaningful bits are different,
regardless of whether the input is sign-extended or not.  The same
technique is already used in the inline version.

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]