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? Richard