Mike Stump <[email protected]> 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
