Mike Stump <mikest...@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?


Reply via email to