Commit Message

On Mar 23, 2012, at 3:01 AM, Richard Sandiford wrote:
> ...it doesn't mean that we interpret the value as a negative _rtx_.> As with all rtx calculations, things like signedness and saturation are> decided by the operation rather than the "type" ("type" == rtx mode).
Ah... [ light goes on ] Let me adjust the documentation to be exceptionally clear in this case. Check out the new wording on const_int, const_double and on immed_double_const. I fixed simplify_const_unary_operation to match your suggestion.
> Sorry for the rather rambling explanation :-) I still think the> version I suggested for this hunk is right though.
I agree. I now see what I had wrong. Thanks for your patience and explanations. If you like the wording I used in the doc and on immed_double_const, I think we have now resolved all issues. The previous version was bootstraped and regression tested on darwin, fortran, c, c++, objective-c++... I'll do one more run with the update for simplify_const_unary_operation, as that can trip when before it would merely return 0.
Ok?

Comments

Mike Stump <mikestump@comcast.net> writes:
> On Mar 23, 2012, at 3:01 AM, Richard Sandiford wrote:>> ...it doesn't mean that we interpret the value as a negative _rtx_.>> As with all rtx calculations, things like signedness and saturation are>> decided by the operation rather than the "type" ("type" == rtx mode).>> Ah... [ light goes on ] Let me adjust the documentation to be exceptionally clear in this case. Check out the new wording on const_int, const_double and on immed_double_const. I fixed simplify_const_unary_operation to match your suggestion.>>> Sorry for the rather rambling explanation :-) I still think the>> version I suggested for this hunk is right though.>> I agree. I now see what I had wrong. Thanks for your patience and explanations. If you like the wording I used in the doc and on immed_double_const, I think we have now resolved all issues. The previous version was bootstraped and regression tested on darwin, fortran, c, c++, objective-c++... I'll do one more run with the update for simplify_const_unary_operation, as that can trip when before it would merely return 0.>> Ok?>>> Index: doc/rtl.texi> ===================================================================> --- doc/rtl.texi (revision 185706)> +++ doc/rtl.texi (working copy)> @@ -1479,8 +1479,13 @@ This type of expression represents the i> is customarily accessed with the macro @code{INTVAL} as in> @code{INTVAL (@var{exp})}, which is equivalent to @code{XWINT (@var{exp}, 0)}.> > -Constants generated for modes with fewer bits than @code{HOST_WIDE_INT}> -must be sign extended to full width (e.g., with @code{gen_int_mode}).> +Constants generated for modes with fewer bits than in> +@code{HOST_WIDE_INT} must be sign extended to full width (e.g., with> +@code{gen_int_mode}). For constants for modes with more bits than in> +@code{HOST_WIDE_INT} the implied high order bits of that constant are> +copies of the top bit, however values are neither signed nor unsigned.> +All operations defined on such constants define the signededness.
I'm not someone who should be wordsmithing, but I think:
...copies of the top bit. Note however that values are neither inherently
signed nor inherently unsigned; where necessary, signedness is determined
by the rtl operation instead.
> @@ -1510,7 +1515,12 @@ Represents either a floating-point const> integer constant too large to fit into @code{HOST_BITS_PER_WIDE_INT}> bits but small enough to fit within twice that number of bits (GCC> does not provide a mechanism to represent even larger constants). In> -the latter case, @var{m} will be @code{VOIDmode}.> +the latter case, @var{m} will be @code{VOIDmode}. For integral values> +constants for modes with more bits than twice the number in> +@code{HOST_WIDE_INT} the implied high order bits of that constant are> +copies of the top bit of @code{CONST_DOUBLE_HIGH}, however integral> +values are neither signed nor unsigned. All operations defined on> +such constants define the signededness.
Same idea here.
> +/* Return an rtx for the sum of X and the integer C, given that X has> + mode MODE. This routine should be used instead of plus_constant> + when they want to ensure that addition happens in a particular> + mode, which is necessary when x can be a VOIDmode CONST_INT or
Sorry, just noticed, should be "...when X can be..."
Looks good to me otherwise, thanks. Richi?
Richard