rtl: constm64_rtx..const64_rtx

Since times immemorial there has been const_int_rtx for all values from
-64 to 64, but only constm1_rtx..const2_rtx have been available for
convenient use.  Change this, so that we can use all values in
{-64,...,64} in RTL easily.  This matters, because then we we just say
  if (XEXP (x, 1) == const16_rtx)
and things like that, since all const_int in that range are unique.  We
already do for -1, 0, 1, 2, but we could for everything.

2021-06-01  Segher Boessenkool  <segher@kernel.crashing.org>
	* rtl.h (constm64_rtx, ..., constm2_rtx): New.
	(const3_rtx, ..., const64_rtx): New.

doc/
	* rtl.texi (Constants): Document the new names.
---
Tested on powerpc64-linux {-m32,-m64}, but this of course doesn't mean
all that much until any of the new names are actually used.

Is this okay for trunk?


Segher


 gcc/doc/rtl.texi |  20 +++++----
 gcc/rtl.h        | 127 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 137 insertions(+), 10 deletions(-)

Segher Boessenkool <segher@kernel.crashing.org> writes:
> Since times immemorial there has been const_int_rtx for all values from
> -64 to 64, but only constm1_rtx..const2_rtx have been available for
> convenient use.  Change this, so that we can use all values in
> {-64,...,64} in RTL easily.  This matters, because then we we just say
>   if (XEXP (x, 1) == const16_rtx)
> and things like that, since all const_int in that range are unique.  We
> already do for -1, 0, 1, 2, but we could for everything.
>
> 2021-06-01  Segher Boessenkool  <segher@kernel.crashing.org>
> 	* rtl.h (constm64_rtx, ..., constm2_rtx): New.
> 	(const3_rtx, ..., const64_rtx): New.
>
> doc/
> 	* rtl.texi (Constants): Document the new names.
> ---
> Tested on powerpc64-linux {-m32,-m64}, but this of course doesn't mean
> all that much until any of the new names are actually used.
>
> Is this okay for trunk?

No strong objection, but personally I'd rather not add something
that is very specific to VOIDmode CONST_INTs.  I realise it's very
unlikely that we'll ever be able to give CONST_INTs their proper mode
(no-one has the kind of time needed to do that), but I don't think we
should make the switch actively harder either.

How about adding a new inline helper function that tests whether an
rtx is a CONST_INT with a given value?  Then we could have a
__builtin_constant_p shortcut for the [-64, 64] case.  That would
also avoid hard-coding the range.

Thanks,
Richard

>
>
> Segher
>
>
>  gcc/doc/rtl.texi |  20 +++++----
>  gcc/rtl.h        | 127 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 137 insertions(+), 10 deletions(-)
>
> diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
> index 5af71137a878..5dbfb6028095 100644
> --- a/gcc/doc/rtl.texi
> +++ b/gcc/doc/rtl.texi
> @@ -1658,19 +1658,21 @@ 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.
>  
> +@findex constm64_rtx
> +@findex constm1_rtx
>  @findex const0_rtx
>  @findex const1_rtx
>  @findex const2_rtx
> -@findex constm1_rtx
> -There is only one expression object for the integer value zero; it is
> +@findex const64_rtx
> +There is only one expression object for the integer value zero: it is
>  the value of the variable @code{const0_rtx}.  Likewise, the only
> -expression for integer value one is found in @code{const1_rtx}, the only
> -expression for integer value two is found in @code{const2_rtx}, and the
> -only expression for integer value negative one is found in
> -@code{constm1_rtx}.  Any attempt to create an expression of code
> -@code{const_int} and value zero, one, two or negative one will return
> -@code{const0_rtx}, @code{const1_rtx}, @code{const2_rtx} or
> -@code{constm1_rtx} as appropriate.
> +expression for integer value one is found in @code{const1_rtx}, and more
> +generally, the only expression for integer value @var{N} is found in
> +@code{const@var{N}_rtx}, and the only expression for integer value negative
> +@var{N} is found in @code{constm@var{N}_rtx}, both for any @var{N} from 1 up
> +to 64 inclusive.  Any attempt to create an expression of code
> +@code{const_int} and value in that range will return @code{const0_rtx},
> +@code{const1_rtx}, and so on, as appropriate.
>  
>  @findex const_true_rtx
>  Similarly, there is only one object for the integer whose value is
> diff --git a/gcc/rtl.h b/gcc/rtl.h
> index 35178b5bfaca..5429b7a3f4ac 100644
> --- a/gcc/rtl.h
> +++ b/gcc/rtl.h
> @@ -3768,10 +3768,135 @@ extern unsigned int split_all_insns_noflow (void);
>  #define MAX_SAVED_CONST_INT 64
>  extern GTY(()) rtx const_int_rtx[MAX_SAVED_CONST_INT * 2 + 1];
>  
> +#define constm64_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-64])
> +#define constm63_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-63])
> +#define constm62_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-62])
> +#define constm61_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-61])
> +#define constm60_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-60])
> +#define constm59_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-59])
> +#define constm58_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-58])
> +#define constm57_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-57])
> +#define constm56_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-56])
> +#define constm55_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-55])
> +#define constm54_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-54])
> +#define constm53_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-53])
> +#define constm52_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-52])
> +#define constm51_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-51])
> +#define constm50_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-50])
> +#define constm49_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-49])
> +#define constm48_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-48])
> +#define constm47_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-47])
> +#define constm46_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-46])
> +#define constm45_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-45])
> +#define constm44_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-44])
> +#define constm43_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-43])
> +#define constm42_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-42])
> +#define constm41_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-41])
> +#define constm40_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-40])
> +#define constm39_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-39])
> +#define constm38_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-38])
> +#define constm37_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-37])
> +#define constm36_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-36])
> +#define constm35_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-35])
> +#define constm34_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-34])
> +#define constm33_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-33])
> +#define constm32_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-32])
> +#define constm31_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-31])
> +#define constm30_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-30])
> +#define constm29_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-29])
> +#define constm28_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-28])
> +#define constm27_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-27])
> +#define constm26_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-26])
> +#define constm25_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-25])
> +#define constm24_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-24])
> +#define constm23_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-23])
> +#define constm22_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-22])
> +#define constm21_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-21])
> +#define constm20_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-20])
> +#define constm19_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-19])
> +#define constm18_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-18])
> +#define constm17_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-17])
> +#define constm16_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-16])
> +#define constm15_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-15])
> +#define constm14_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-14])
> +#define constm13_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-13])
> +#define constm12_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-12])
> +#define constm11_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-11])
> +#define constm10_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-10])
> +#define constm9_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-9])
> +#define constm8_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-8])
> +#define constm7_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-7])
> +#define constm6_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-6])
> +#define constm5_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-5])
> +#define constm4_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-4])
> +#define constm3_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-3])
> +#define constm2_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-2])
> +#define constm1_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-1])
>  #define const0_rtx	(const_int_rtx[MAX_SAVED_CONST_INT])
>  #define const1_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+1])
>  #define const2_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+2])
> -#define constm1_rtx	(const_int_rtx[MAX_SAVED_CONST_INT-1])
> +#define const3_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+3])
> +#define const4_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+4])
> +#define const5_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+5])
> +#define const6_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+6])
> +#define const7_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+7])
> +#define const8_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+8])
> +#define const9_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+9])
> +#define const10_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+10])
> +#define const11_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+11])
> +#define const12_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+12])
> +#define const13_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+13])
> +#define const14_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+14])
> +#define const15_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+15])
> +#define const16_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+16])
> +#define const17_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+17])
> +#define const18_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+18])
> +#define const19_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+19])
> +#define const20_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+20])
> +#define const21_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+21])
> +#define const22_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+22])
> +#define const23_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+23])
> +#define const24_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+24])
> +#define const25_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+25])
> +#define const26_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+26])
> +#define const27_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+27])
> +#define const28_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+28])
> +#define const29_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+29])
> +#define const30_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+30])
> +#define const31_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+31])
> +#define const32_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+32])
> +#define const33_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+33])
> +#define const34_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+34])
> +#define const35_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+35])
> +#define const36_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+36])
> +#define const37_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+37])
> +#define const38_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+38])
> +#define const39_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+39])
> +#define const40_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+40])
> +#define const41_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+41])
> +#define const42_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+42])
> +#define const43_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+43])
> +#define const44_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+44])
> +#define const45_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+45])
> +#define const46_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+46])
> +#define const47_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+47])
> +#define const48_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+48])
> +#define const49_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+49])
> +#define const50_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+50])
> +#define const51_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+51])
> +#define const52_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+52])
> +#define const53_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+53])
> +#define const54_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+54])
> +#define const55_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+55])
> +#define const56_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+56])
> +#define const57_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+57])
> +#define const58_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+58])
> +#define const59_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+59])
> +#define const60_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+60])
> +#define const61_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+61])
> +#define const62_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+62])
> +#define const63_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+63])
> +#define const64_rtx	(const_int_rtx[MAX_SAVED_CONST_INT+64])
>  extern GTY(()) rtx const_true_rtx;
>  
>  extern GTY(()) rtx const_tiny_rtx[4][(int) MAX_MACHINE_MODE];

Hi!

On Wed, Jun 02, 2021 at 06:07:28PM +0100, Richard Sandiford wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > Since times immemorial there has been const_int_rtx for all values from
> > -64 to 64, but only constm1_rtx..const2_rtx have been available for
> > convenient use.  Change this, so that we can use all values in
> > {-64,...,64} in RTL easily.  This matters, because then we we just say
> >   if (XEXP (x, 1) == const16_rtx)
> > and things like that, since all const_int in that range are unique.  We
> > already do for -1, 0, 1, 2, but we could for everything.

> No strong objection, but personally I'd rather not add something
> that is very specific to VOIDmode CONST_INTs.  I realise it's very
> unlikely that we'll ever be able to give CONST_INTs their proper mode
> (no-one has the kind of time needed to do that), but I don't think we
> should make the switch actively harder either.

How does this make that harder?

Having no mode for CONST_INTs makes some things significantly *easier*
btw.  Well you know that, that is what makes any conversion away from
this so much harder :-)

We have has const0_rtx etc. since forever, this patch just increases the
range (to those values that have had guaranteed unique RTXes since
decades as well).

> How about adding a new inline helper function that tests whether an
> rtx is a CONST_INT with a given value?  Then we could have a
> __builtin_constant_p shortcut for the [-64, 64] case.  That would
> also avoid hard-coding the range.

Currently you have to write the example as
  if (XEXP (x, 1) == const_int_rtx[MAX_SAVED_CONST_INT + 16])
and with your suggestion it will be
  if (is_const_int_with_value (XEXP (x, 1), 16))

I like
  if (XEXP (x, 1) == const16_rtx)
better: it is shorter and clearer (often you have something like this is
more complex conditionals, it matters), and this pattern is already very
well known (for -1, 0, 1, 2).

Do you like this patch a bit better if I also add such an
is_const_int_with_value function?


Segher

On 6/2/2021 4:43 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jun 02, 2021 at 06:07:28PM +0100, Richard Sandiford wrote:
>> Segher Boessenkool <segher@kernel.crashing.org> writes:
>>> Since times immemorial there has been const_int_rtx for all values from
>>> -64 to 64, but only constm1_rtx..const2_rtx have been available for
>>> convenient use.  Change this, so that we can use all values in
>>> {-64,...,64} in RTL easily.  This matters, because then we we just say
>>>    if (XEXP (x, 1) == const16_rtx)
>>> and things like that, since all const_int in that range are unique.  We
>>> already do for -1, 0, 1, 2, but we could for everything.
>> No strong objection, but personally I'd rather not add something
>> that is very specific to VOIDmode CONST_INTs.  I realise it's very
>> unlikely that we'll ever be able to give CONST_INTs their proper mode
>> (no-one has the kind of time needed to do that), but I don't think we
>> should make the switch actively harder either.
> How does this make that harder?
>
> Having no mode for CONST_INTs makes some things significantly *easier*
> btw.  Well you know that, that is what makes any conversion away from
> this so much harder :-)
>
> We have has const0_rtx etc. since forever, this patch just increases the
> range (to those values that have had guaranteed unique RTXes since
> decades as well).
Yea, but often what you really want is CONST0_RTX (mode) instead of 
const0_rtx.   It's easily goof'd and often the cause minor missed 
optimizations.

jeff

On Thu, Jun 03, 2021 at 01:32:54PM -0600, Jeff Law wrote:
> On 6/2/2021 4:43 PM, Segher Boessenkool wrote:
> >We have has const0_rtx etc. since forever, this patch just increases the
> >range (to those values that have had guaranteed unique RTXes since
> >decades as well).
> Yea, but often what you really want is CONST0_RTX (mode) instead of 
> const0_rtx.   It's easily goof'd and often the cause minor missed 
> optimizations.

I'd say "sometimes" instead of "often"...  almost always you really do
want a scalar integer.  Also, although CONST0_RTX makes sense for pretty
much all modes, CONST64_RTX will not (and those are not currently unique
RTX anyway).


Segher

Segher Boessenkool <segher@kernel.crashing.org> writes:
> On Wed, Jun 02, 2021 at 06:07:28PM +0100, Richard Sandiford wrote:
>> Segher Boessenkool <segher@kernel.crashing.org> writes:
>> > Since times immemorial there has been const_int_rtx for all values from
>> > -64 to 64, but only constm1_rtx..const2_rtx have been available for
>> > convenient use.  Change this, so that we can use all values in
>> > {-64,...,64} in RTL easily.  This matters, because then we we just say
>> >   if (XEXP (x, 1) == const16_rtx)
>> > and things like that, since all const_int in that range are unique.  We
>> > already do for -1, 0, 1, 2, but we could for everything.
>
>> No strong objection, but personally I'd rather not add something
>> that is very specific to VOIDmode CONST_INTs.  I realise it's very
>> unlikely that we'll ever be able to give CONST_INTs their proper mode
>> (no-one has the kind of time needed to do that), but I don't think we
>> should make the switch actively harder either.
>
> How does this make that harder?
>
> Having no mode for CONST_INTs makes some things significantly *easier*
> btw.  Well you know that, that is what makes any conversion away from
> this so much harder :-)

Sure, most things have advantages and disadvantages.  The same was
true for cc0: it made some things easier for ports.

> We have has const0_rtx etc. since forever, this patch just increases the
> range (to those values that have had guaranteed unique RTXes since
> decades as well).

But it will change the preferred way of writing something.  If we do
this, then whenever any future patch happens to use an integer in the
expanded range, it will be a legitimate review comment to say that
you should use const31_rtx instead of GEN_INT (31), or should use
x == const31_rtx instead of testing the contents of x.  If instead
the constant is outside [-64, 64] then the code should do whatever it
would have done before.  This is something new that people will have
to remember.  The current range of [-64, 64] might have been around for
a long time, but it's not something that people have had to internalise
until now.

IMO the range of cached integers is an implementation detail that could
in principle change in future based on profiling.  It's not something
that we should hard-code into the interface to this extent.

And like Jeff says, at least const{m1,0,1,2}_rtx have generic
macros CONST{M1,0,1,2}_RTX that work for non-integer modes.
Adding constN_rtx macros that have no CONSTN_RTX version is new ground.
The (existing) constN_rtx names aren't great because they don't
make it clear that the rtx is specifically for scalar integers.

>> How about adding a new inline helper function that tests whether an
>> rtx is a CONST_INT with a given value?  Then we could have a
>> __builtin_constant_p shortcut for the [-64, 64] case.  That would
>> also avoid hard-coding the range.
>
> Currently you have to write the example as
>   if (XEXP (x, 1) == const_int_rtx[MAX_SAVED_CONST_INT + 16])
> and with your suggestion it will be
>   if (is_const_int_with_value (XEXP (x, 1), 16))

Why the long function name though?  IMO:

   if (is_const_int (XEXP (x, 1), 16))

would be fine.  Maybe even:

   if (is_int (XEXP (x, 1), 16))

since GEN_INT, gen_int_mode and (U)INTVAL also drop the “const_”.

> I like
>   if (XEXP (x, 1) == const16_rtx)
> better: it is shorter and clearer (often you have something like this is
> more complex conditionals, it matters), and this pattern is already very
> well known (for -1, 0, 1, 2).

Well, it depends on the context.  These days the preferred way of
writing GET_CODE (x) == CONST_INT is CONST_INT_P (x), so the new test
would typically be replacing another function-like test.  It seems
inconsistent to say that CONST_INT_P (x) is more readable than a ==
condition when testing for specific codes, but == is more readable
than a predicate when testing for specific integer rtxes.

> Do you like this patch a bit better if I also add such an
> is_const_int_with_value function?

Not really, sorry. :-)

But anyway, I've said my piece.  Let's see whether anyone else is
prepared to approve it.

Thanks,
Richard