RFA: Add support for Renesas RX architecture to GCC (take 2)

RFA: Add support for Renesas RX architecture to GCC (take 2)

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]

Hi Guys,

  Here is a revised submission of the RX port for GCC.  I have tried
  to resolve all of the issues raised by Joseph and Richard (thanks
  for the reviews!).  Although there is no changelog entry for it,
  this patch does also include an update to the webpages mentioning
  the contribution of support for the new architecture.

  OK to apply ?

Cheers
  Nick

./ChangeLog
2009-10-08  Nick Clifton  <nickc@redhat.com>

	* MAINTAINERS: Add myself as a maintainer for the RX port.

gcc/ChangeLog
2009-10-08  Nick Clifton  <nickc@redhat.com>

	* config.gcc: Add support for RX target.
	* config/rx: New directory.
	* config/rx/constraints.md: New file.
	* config/rx/predicates.md: New file.
	* config/rx/rx.c: New file.
	* config/rx/rx.h: New file.
	* config/rx/rx.md: New file.
	* config/rx/rx.opt: New file.
	* config/rx/rx-protos.h: New file.
	* config/rx/t-rx: New file.
	* doc/extend.texi: Document RX function attributes.
	* doc/invoke.texi: Document RX specific command line options.
	* doc/contrib.texi: Document RX contribution.
	* doc/md.texi: Document RX constraints.
	* doc/install.texi: Document RX support.

libgcc/ChangeLog
2009-10-08  Nick Clifton  <nickc@redhat.com>

	* config.host: Add support for RX target.
	* config/rx: New directory.
	* config/rx/rx-abi-functions.c: New file. Supplementary
	functions for libgcc to support the RX ABI.
	* config/rx/rx-abi.h: New file.  Supplementary header file for
	libgcc RX ABI functions.
	* config/rx/t-rx: New file: Makefile fragment for building
	libgcc for the RX.

gcc/testsuite/ChangeLog
2009-10-08  Nick Clifton  <nickc@redhat.com>

	* lib/target-supports.exp (check_profiling_available):
	Profiling is not, currently, available for the RX port.
	(check_effective_target_hard_float): Add support for RX
	target.
	* gcc.target/rx: New directory.
	* gcc.target/rx/builtins.c: New test file.
	* gcc.target/rx/interrupts.c: New test file.
	* gcc.target/rx/rx-abi-function-tests.c: New test file.
	* gcc.target/rx/zero-width-bitfield.c: New test file.
	* gcc.target/rx/i272091.c: New test file.
	* gcc.target/rx/packed-struct.c: New test file.
	* gcc.target/rx/rx.exp: New file: Drives RX tests.
	

[-- Attachment #2: rx-gcc.patch.2.svn.lzma --]
[-- Type: application/octet-stream, Size: 5726 bytes --]

[-- Attachment #3: rx-gcc.patch.2.cvs.lzma --]
[-- Type: application/octet-stream, Size: 913 bytes --]

[-- Attachment #4: rx-gcc.patch.2.files.lzma --]
[-- Type: application/octet-stream, Size: 35192 bytes --]

Re: RFA: Add support for Renesas RX architecture to GCC (take 2)

[Joseph S. Myers]

On Thu, 8 Oct 2009, Nick Clifton wrote:

> +@item Int08
> +A constant in the range -256 to 255, inclusive.
> +
> +@item Sint08
> +A constant in the range -128 to 127, inclusive.
> +
> +@item Sint16
> +A constant in the range -32768 to 32767, inclusive.
> +
> +@item Sint24
> +A constant in the range -32768 to 32767, inclusive.
> +
> +@item Uint08
> +A constant in the range -8388608 to 8388607, inclusive.

All of these should use @minus{} for the minus sign.

> + 	      if (! warned)
> + 		{
> + 		  warning (0, "no fixed registers available \
> + for use by fast interrupt handler");

It looks like this will have two consecutive spaces in the middle of the 
string.  Generally we use C90 string concatenation if the string won't fit 
conveniently on one source file, rather than backslash-newline.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: RFA: Add support for Renesas RX architecture to GCC (take 2)

[Richard Henderson]

> + (define_constraint "Int08"
> +   "@internal An signed or unsigned 8-bit immediate value"
> +   (and (match_code "const_int")
> +        (and (match_test "ival >= -256")
> +           (match_test "ival <   256")
> +        )
> +   )
> + )

I think I mentioned this before -- IN_RANGE_P.

> + (define_memory_constraint "Q"
> +   "A MEM which does not use REG+REG, REG+(REG*SCALE), --REG or REG++ addressing."
> +   (and (match_code "mem")
> +        (ior (and (match_test "GET_CODE (XEXP (op,0)) == PLUS")
> +                (and (match_test "RX_REG_P (XEXP (XEXP (op, 0), 0))")
> +                     (match_test "CONST_INT_P (XEXP (XEXP (op, 0), 1))")
> +                )
> +           )
> +          (match_test "GET_CODE (XEXP (op, 0)) == REG")
> +        )
> +    )
> + )

Consider using e.g.

  (match_code "plus" "0")
  (match_code "reg" "00")
  (match_code "const_int" "01")
  (match_code "reg" "0")

> + static unsigned int
> + bit_count (unsigned int x)
> + {
> +   const unsigned int m1 = 0x55555555;
> +   const unsigned int m2 = 0x33333333;
> +   const unsigned int m4 = 0x0f0f0f0f;
> +
> +   x -= (x >> 1) & m1;
> +   x = (x & m2) + ((x >> 2) & m2);
> +   x = (x + (x >> 4)) & m4;
> +   x += x >>  8;
> +
> +   return (x + (x >> 16)) & 0x3f;

We should probably have this function moved to somewhere generic.  We 
have several places within gcc that we compute a population count. 
Search for popcount within the toplevel gcc sources.

> +   ADD_RX_BUILTIN2 (TST,     "tst",     void,  intSI,  intSI);

One last cc0-setting builtin that isn't usable.

> +   ADD_RX_BUILTIN1 (PUSHC,   "pushc",   void,  integer);
> +   ADD_RX_BUILTIN1 (POPC,    "popc",    void,  integer);

These are a bit questionable, seeing as how they manipulate the stack 
register.  Consider either removing them, or having them force the 
function to use a frame pointer?

> + /* These addressing modes only work for SImode.  */
> + #define GO_IF_MODE_DEPENDENT_ADDRESS(ADDR, LABEL)                     \
> +   do                                                                  \
> +     {                                                                 \
> +       if (GET_CODE (ADDR) == PRE_DEC || GET_CODE (ADDR) == POST_INC)  \
> +       goto LABEL;                                                     \
> +       if (GET_CODE (ADDR) == PLUS                                     \
> +         && REG_P (XEXP (ADDR, 0))                                     \
> +         && REG_P (XEXP (ADDR, 1)))                                    \
> +       goto LABEL;                                                     \
> +     }                                                                 \
> +   while (0)

Aren't there lots more addressing modes that are mode dependant?  E.g.

   (mem:QI (plus:SI (reg) (const_int 1)))
   (mem:SI (plus:SI (reg) (const_int 131074)))
   (mem:SI (plus:SI (mult:SI (reg) (const_int 4)))

I.e. the only addresses that aren't mode dependent are plain registers 
and reg+const where const is a multiple of 4 and also small enough to 
fit a byte offset.

Please move the contents of the macro into a function.

> +     /* Control registers:  */         \
> +   , { "psw",   0x0 }                  \
> +   , { "pc",    0x1 }                  \
> +   , { "usp",   0x2 }                  \
> +   , { "fpsw",  0x3 }                  \
> +   , { "bpsw",  0x8 }                  \
> +   , { "bpc",   0x9 }                  \
> +   , { "isp",   0xa }                  \
> +   , { "fintv", 0xb }                  \
> +   , { "intb",  0xc }                  \

These should not be in the same namespace with ADDITONAL_REGISTER_NAMES.

> + (define_insn "stack_pushm"
> +   [(set:SI (reg:SI SP_REG)
> +          (minus:SI (reg:SI SP_REG)
> +                    (match_operand:SI        0 "immediate_operand" "i")))
> +    (match_parallel                            1 "rx_store_multiple_vector"
> +                  [(set:SI (match_operand:SI 2 "memory_operand"   "=m")
> +                           (match_operand:SI 3 "register_operand"  "r"))])]

All of your uses of match_parallel are incorrect.  You wind up 
generating nested PARALLEL patterns.  The only thing that should be 
present within a define_insn that uses it is a top-level match_parallel. 
  This results in patterns like

  (define_insn "stack_pushm"
     [(match_parallel 1 "rx_pushm_parallel"
	[(set (reg:SI SP_REG)
	   (minus:SI (reg:SI SP_REG)
		     (match_operand:SI 0 "const_int_operand" "n")))])]

where the stack adjust is pushed inside of the parallel

> + (define_insn "subsi3"
> +   [(set (match_operand:SI           0 "register_operand" "=r,r,r,r,r")
> +       (minus:SI (match_operand:SI 1 "register_operand"  "0,0,0,r,0")
> +                 (match_operand:SI 2 "rx_source_operand" "r,Uint04,i,r,Q")))]
> +   ""
> +   "@
> +   sub\t%2, %0
> +   sub\t%2, %0
> +   add\t%N2, %0

That's 'n' not 'i' since you can't negate symbol addresses.  That said, 
I'm not sure you should ever see a (minus reg const_int), since I'm 
pretty sure we canonicalize on (plus reg const_int).

> + (define_insn "addsf3"
> +   [(set (match_operand:SF          0 "register_operand"  "=r,r,r")
> +       (plus:SF (match_operand:SF 1 "register_operand"  "%0,0,0")
> +                (match_operand:SF 2 "rx_source_operand"  "r,F,Q")))]
> +   "! TARGET_64BIT_DOUBLES || fast_math_flags_set_p ()"

You took me literally with "-ffast-math" I see.  I really expected you 
to de-couple -m64bit-double from -mieee.  I think -m64bit-double should 
not affect SFmode *at all*.

Either you have a -mieee that disables the hw instructions that can't 
handle subnormals, or you conditionalize all of these patterns on 
flag_unsafe_math_optimizations only.  Although really one could argue 
for a new flag -f{no-,}subnormal-math that's also adjusted by 
-ffast-math instead.

> + ;; Byte swap (single 32-bit value).
> + (define_insn "revl"
> +   [(set (match_operand:SI           0 "register_operand" "+r")
> +       (bswap:SI (match_operand:SI 1 "register_operand"  "r")))]
> +   ""
> +   "revl\t%1, %0"
> +   [(set_attr "length" "3")]
> + )

s/+/=/

> + (define_insn "rolc"
> + (define_insn "rorc"
> + (define_insn "satr"

Depends on cc0, and so isn't reliable.

I am moderately surprised that you aren't representing the accumulator 
as a special hard register, kinda like the mips multiplier.

> + (define_insn "round"
> +   [(set (match_operand:SI                      0 "register_operand"  "=r,r")
> +       (unspec_volatile:SI [(match_operand:SF 1 "rx_compare_operand" "r,Q")]
> +                           UNSPEC_BUILTIN_ROUND))]
> +   ""
> +   "round\t%1, %0"
> +   [(set_attr "cc" "set_zs")
> +    (set_attr "timings" "22,44")
> +    (set_attr "length" "3,5")]
> + )

This should be lrintsf2.  And you really don't need the volatile.

> + (define_insn "sync_lock_test_and_setsi"
> +   [(parallel

Nested parallel; define_expand needs an explicit parallel, but 
define_insn doesn't.

> + (define_insn "xchg"

Why?  You've already got the sync pattern.



r~

RFA: Adding @minus{} to gcc documentation

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

Hi Joseph.

> All of these should use @minus{} for the minus sign.

Ah - thanks for the pointer.  In which case, would you care to review 
the attached patch which replaces the '-' character with @minus{} in the 
current documentation files, in places where it is being used as a minus 
sign ?

Cheers
   Nick

gcc/ChangeLog
2009-10-13  Nick Clifton  <nickc@redhat.com>

	* gcc/doc/extended.texi: Replace the dash character with
	@minus{} in situations where it is being used as a minus
	symbol.
	* gcc/doc/tm.texi: Likewise.
	* gcc/doc/invoke.texi: Likewise.
	* gcc/doc/md.texi: Likewise.





[-- Attachment #2: minus.patch --]
[-- Type: text/x-diff, Size: 12051 bytes --]

Index: gcc/doc/extend.texi
===================================================================
--- gcc/doc/extend.texi	(revision 152662)
+++ gcc/doc/extend.texi	(working copy)
@@ -935,7 +935,7 @@
 use it consistently in your program.
 
 Specifying @option{-mfp16-format=ieee} selects the IEEE 754-2008 format.
-This format can represent normalized values in the range of @math{2^{-14}} to 65504.
+This format can represent normalized values in the range of @math{2^{@minus{}14}} to 65504.
 There are 11 bits of significand precision, approximately 3
 decimal digits.
 
@@ -943,7 +943,7 @@
 alternative format.  This representation is similar to the IEEE
 format, but does not support infinities or NaNs.  Instead, the range
 of exponents is extended, so that this format can represent normalized
-values in the range of @math{2^{-14}} to 131008.
+values in the range of @math{2^{@minus{}14}} to 131008.
 
 The @code{__fp16} type is a storage format only.  For purposes
 of arithmetic and other operations, @code{__fp16} values in C or C++
@@ -2039,7 +2039,7 @@
 which will include @var{message} will be diagnosed.  This is useful
 for compile time checking, especially together with @code{__builtin_constant_p}
 and inline functions where checking the inline function arguments is not
-possible through @code{extern char [(condition) ? 1 : -1];} tricks.
+possible through @code{extern char [(condition) ? 1 : @minus{}1];} tricks.
 While it is possible to leave the function undefined and thus invoke
 a link failure, when using this attribute the problem will be diagnosed
 earlier and with exact location of the call even in presence of inline
@@ -6278,13 +6285,13 @@
 @var{ptr} to the end of the object @var{ptr} pointer points to
 (if known at compile time).  @code{__builtin_object_size} never evaluates
 its arguments for side-effects.  If there are any side-effects in them, it
-returns @code{(size_t) -1} for @var{type} 0 or 1 and @code{(size_t) 0}
+returns @code{(size_t) @minus{}1} for @var{type} 0 or 1 and @code{(size_t) 0}
 for @var{type} 2 or 3.  If there are multiple objects @var{ptr} can
 point to and all of them are known at compile time, the returned number
 is the maximum of remaining byte counts in those objects if @var{type} & 2 is
 0 and minimum if nonzero.  If it is not possible to determine which objects
 @var{ptr} points to at compile time, @code{__builtin_object_size} should
-return @code{(size_t) -1} for @var{type} 0 or 1 and @code{(size_t) 0}
+return @code{(size_t) @minus{}1} for @var{type} 0 or 1 and @code{(size_t) 0}
 for @var{type} 2 or 3.
 
 @var{type} is an integer constant from 0 to 3.  If the least significant
@@ -6313,10 +6320,10 @@
 functions, e.g., for @code{memcpy} @code{__builtin___memcpy_chk}
 built-in is provided.  This built-in has an additional last argument,
 which is the number of bytes remaining in object the @var{dest}
-argument points to or @code{(size_t) -1} if the size is not known.
+argument points to or @code{(size_t) @minus{}1} if the size is not known.
 
 The built-in functions are optimized into the normal string functions
-like @code{memcpy} if the last argument is @code{(size_t) -1} or if
+like @code{memcpy} if the last argument is @code{(size_t) @minus{}1} or if
 it is known at compile time that the destination object will not
 be overflown.  If the compiler can determine at compile time the
 object will be always overflown, it issues a warning.
@@ -6369,10 +6376,10 @@
 
 The @var{os} argument is the object size @var{s} points to, like in the
 other built-in functions.  There is a small difference in the behavior
-though, if @var{os} is @code{(size_t) -1}, the built-in functions are
+though, if @var{os} is @code{(size_t) @minus{}1}, the built-in functions are
 optimized into the non-checking functions only if @var{flag} is 0, otherwise
 the checking function is called with @var{os} argument set to
-@code{(size_t) -1}.
+@code{(size_t) @minus{}1}.
 
 In addition to this, there are checking built-in functions
 @code{__builtin___printf_chk}, @code{__builtin___vprintf_chk},
@@ -9732,7 +9740,7 @@
 
 @item int __builtin_subs (int @var{x}, int @var{y})
 Saturating subtraction.  Return the result of subtracting @var{y} from
-@var{x}, storing the value -32768 if the result overflows.
+@var{x}, storing the value @minus{}32768 if the result overflows.
 
 @item void __builtin_halt (void)
 Halt.  The processor will stop execution.  This built-in is useful for
Index: gcc/doc/tm.texi
===================================================================
--- gcc/doc/tm.texi	(revision 152662)
+++ gcc/doc/tm.texi	(working copy)
@@ -1918,7 +1918,7 @@
 
 @defmac FIRST_PSEUDO_REGISTER
 Number of hardware registers known to the compiler.  They receive
-numbers 0 through @code{FIRST_PSEUDO_REGISTER-1}; thus, the first
+numbers 0 through @code{FIRST_PSEUDO_REGISTER @minus{} 1}; thus, the first
 pseudo register's number really is assigned the number
 @code{FIRST_PSEUDO_REGISTER}.
 @end defmac
@@ -5400,7 +5399,7 @@
 must be rejected.  For non-hard registers, the strict variant should look
 up the @code{reg_renumber} array; it should then proceed using the hard
 register number in the array, or treat the pseudo as a memory reference
-if the array holds @code{-1}.
+if the array holds @code{@minus{}1}.
 
 The non-strict variant is used in other passes.  It must be defined to
 accept all pseudo-registers in every context where some kind of
@@ -5628,7 +5627,7 @@
 described above.
 If this hook is not defined, then @var{addr} will be used as
 the argument @var{OFF} to @code{REALIGN_LOAD}, in which case the low
-log2(@var{VS})-1 bits of @var{addr} will be considered.
+log2(@var{VS}) @minus{} 1 bits of @var{addr} will be considered.
 @end deftypefn
 
 @deftypefn {Target Hook} tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN (tree @var{x})
@@ -6610,7 +6618,7 @@
 The hook is used to check if the pattern of @var{insn} has a speculative
 version and, in case of successful check, to generate that speculative
 pattern.  The hook should return 1, if the instruction has a speculative form,
-or -1, if it doesn't.  @var{request} describes the type of requested
+or @minus{}1, if it doesn't.  @var{request} describes the type of requested
 speculation.  If the return value equals 1 then @var{new_pat} is assigned
 the generated speculative pattern.
 @end deftypefn
@@ -9260,7 +9268,7 @@
 @deftypefn Macro int REAL_VALUES_EQUAL (REAL_VALUE_TYPE @var{x}, REAL_VALUE_TYPE @var{y})
 Compares for equality the two values, @var{x} and @var{y}.  If the target
 floating point format supports negative zeroes and/or NaNs,
-@samp{REAL_VALUES_EQUAL (-0.0, 0.0)} is true, and
+@samp{REAL_VALUES_EQUAL (@minus{}0.0, 0.0)} is true, and
 @samp{REAL_VALUES_EQUAL (NaN, NaN)} is false.
 @end deftypefn
 
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi	(revision 152662)
+++ gcc/doc/invoke.texi	(working copy)
@@ -3809,9 +3819,9 @@
 Warn for implicit conversions that may alter a value. This includes
 conversions between real and integer, like @code{abs (x)} when
 @code{x} is @code{double}; conversions between signed and unsigned,
-like @code{unsigned ui = -1}; and conversions to smaller types, like
+like @code{unsigned ui = @minus{}1}; and conversions to smaller types, like
 @code{sqrtf (M_PI)}. Do not warn for explicit casts like @code{abs
-((int) x)} and @code{ui = (unsigned) -1}, or if the value is not
+((int) x)} and @code{ui = (unsigned) @minus{}1}, or if the value is not
 changed by the conversion like in @code{abs (2.0)}.  Warnings about
 conversions between signed and unsigned integers can be disabled by
 using @option{-Wno-sign-conversion}.
@@ -9847,7 +9858,7 @@
 @code{pc} stored at @code{fp + 0}.  If the trace function then looks at
 location @code{pc - 12} and the top 8 bits are set, then we know that
 there is a function name embedded immediately preceding this location
-and has length @code{((pc[-3]) & 0xff000000)}.
+and has length @code{((pc[@minus{}3]) & 0xff000000)}.
 
 @item -mthumb
 @opindex mthumb
Index: gcc/doc/md.texi
===================================================================
--- gcc/doc/md.texi	(revision 152662)
+++ gcc/doc/md.texi	(working copy)
@@ -1756,7 +1756,7 @@
 A floating point constant 0.0
 
 @item R
-Integer constant in the range -6 @dots{} 5.
+Integer constant in the range @minus{}6 @dots{} 5.
 
 @item Q
 A memory address based on Y or Z pointer with displacement.
@@ -1787,7 +1787,7 @@
 Constant that fits in 5 bits
 
 @item L
-Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
+Constant that is one of @minus{}1, 4, @minus{}4, 7, 8, 12, 16, 20, 32, 48
 
 @item G
 Floating point constant that is legal for store immediate
@@ -2381,13 +2381,13 @@
 Any register except accumulators or CC.
 
 @item Ksh
-Signed 16 bit integer (in the range -32768 to 32767)
+Signed 16 bit integer (in the range @minus{}32768 to 32767)
 
 @item Kuh
 Unsigned 16 bit integer (in the range 0 to 65535)
 
 @item Ks7
-Signed 7 bit integer (in the range -64 to 63)
+Signed 7 bit integer (in the range @minus{}64 to 63)
 
 @item Ku7
 Unsigned 7 bit integer (in the range 0 to 127)
@@ -2396,10 +2396,10 @@
 Unsigned 5 bit integer (in the range 0 to 31)
 
 @item Ks4
-Signed 4 bit integer (in the range -8 to 7)
+Signed 4 bit integer (in the range @minus{}8 to 7)
 
 @item Ks3
-Signed 3 bit integer (in the range -3 to 4)
+Signed 3 bit integer (in the range @minus{}3 to 4)
 
 @item Ku3
 Unsigned 3 bit integer (in the range 0 to 7)
@@ -2511,28 +2511,28 @@
 Used to match function return values.
 
 @item Is3
--8 @dots{} 7
+@minus{}8 @dots{} 7
 
 @item IS1
--128 @dots{} 127
+@minus{}128 @dots{} 127
 
 @item IS2
--32768 @dots{} 32767
+@minus{}32768 @dots{} 32767
 
 @item IU2
 0 @dots{} 65535
 
 @item In4
--8 @dots{} -1 or 1 @dots{} 8
+@minus{}8 @dots{} @minus{}1 or 1 @dots{} 8
 
 @item In5
--16 @dots{} -1 or 1 @dots{} 16
+@minus{}16 @dots{} @minus{}1 or 1 @dots{} 16
 
 @item In6
--32 @dots{} -1 or 1 @dots{} 32
+@minus{}32 @dots{} @minus{}1 or 1 @dots{} 32
 
 @item IM2
--65536 @dots{} -1
+@minus{}65536 @dots{} @minus{}1
 
 @item Ilb
 An 8 bit value with exactly one bit set.
@@ -2717,7 +2717,7 @@
 or @code{ori}.
 
 @item N
-A constant in the range -65535 to -1 (inclusive).
+A constant in the range @minus{}65535 to @minus{}1 (inclusive).
 
 @item O
 A signed 15-bit constant.
@@ -2893,7 +2893,7 @@
 A constant in the range of 0 to 255.
 
 @item N
-A constant in the range of 0 to -255.
+A constant in the range of 0 to @minus{}255.
 
 @end table
 
@@ -3012,7 +3038,7 @@
 An immediate for the @code{iohl} instruction.  const_int is treated as a 32 bit value.  
 
 @item I
-A constant in the range [-64, 63] for shift/rotate instructions.  
+A constant in the range [@minus{}64, 63] for shift/rotate instructions.  
 
 @item J
 An unsigned 7-bit constant for conversion/nop/channel instructions.  
@@ -3083,7 +3109,7 @@
 @table @code
 @item (0..4095)
 for short displacement
-@item (-524288..524287)
+@item (@minus{}524288..524287)
 for long displacement
 @end table
 
@@ -4426,7 +4452,7 @@
 respectively.  The expected alignment differs from alignment in operand 4
 in a way that the blocks are not required to be aligned according to it in
 all cases. This expected alignment is also in bytes, just like operand 4.
-Expected size, when unknown, is set to @code{(const_int -1)}.
+Expected size, when unknown, is set to @code{(const_int @minus{}1)}.
 
 Descriptions of multiple @code{movmem@var{m}} patterns can only be
 beneficial if the patterns for smaller modes have fewer restrictions
@@ -4464,7 +4490,7 @@
 respectively.  The expected alignment differs from alignment in operand 4
 in a way that the blocks are not required to be aligned according to it in
 all cases. This expected alignment is also in bytes, just like operand 4.
-Expected size, when unknown, is set to @code{(const_int -1)}.
+Expected size, when unknown, is set to @code{(const_int @minus{}1)}.
 
 The use for multiple @code{setmem@var{m}} is as for @code{movmem@var{m}}.
 

Re: RFA: Adding @minus{} to gcc documentation

[Joseph S. Myers]

On Tue, 13 Oct 2009, Nick Clifton wrote:

> Hi Joseph.
> 
> > All of these should use @minus{} for the minus sign.
> 
> Ah - thanks for the pointer.  In which case, would you care to review the
> attached patch which replaces the '-' character with @minus{} in the current
> documentation files, in places where it is being used as a minus sign ?

@minus{} should be used where what is being represented is a number, or 
subtraction in English text, not when it is a piece of C source code (C 
uses the ASCII HYPHEN-MINUS).  (Similarly, @dots{} represents ellipsis, 
and it's incorrect to use it for the literal "..." token of C.)

Thus (presuming the results look right in the output of "make dvi" or 
"make pdf" without breaking "make info" and "make html"):

> -This format can represent normalized values in the range of @math{2^{-14}} to 65504.
> +This format can represent normalized values in the range of @math{2^{@minus{}14}} to 65504.

OK.

> -values in the range of @math{2^{-14}} to 131008.
> +values in the range of @math{2^{@minus{}14}} to 131008.

OK.

> -possible through @code{extern char [(condition) ? 1 : -1];} tricks.
> +possible through @code{extern char [(condition) ? 1 : @minus{}1];} tricks.

Not OK.

> -returns @code{(size_t) -1} for @var{type} 0 or 1 and @code{(size_t) 0}
> +returns @code{(size_t) @minus{}1} for @var{type} 0 or 1 and @code{(size_t) 0}

Not OK.

> -return @code{(size_t) -1} for @var{type} 0 or 1 and @code{(size_t) 0}
> +return @code{(size_t) @minus{}1} for @var{type} 0 or 1 and @code{(size_t) 0}

Not OK.

> -argument points to or @code{(size_t) -1} if the size is not known.
> +argument points to or @code{(size_t) @minus{}1} if the size is not known.

Not OK.

> -like @code{memcpy} if the last argument is @code{(size_t) -1} or if
> +like @code{memcpy} if the last argument is @code{(size_t) @minus{}1} or if

Not OK.

> -though, if @var{os} is @code{(size_t) -1}, the built-in functions are
> +though, if @var{os} is @code{(size_t) @minus{}1}, the built-in functions are

Not OK.

> -@code{(size_t) -1}.
> +@code{(size_t) @minus{}1}.

Not OK.

> -@var{x}, storing the value -32768 if the result overflows.
> +@var{x}, storing the value @minus{}32768 if the result overflows.

OK.

> -numbers 0 through @code{FIRST_PSEUDO_REGISTER-1}; thus, the first
> +numbers 0 through @code{FIRST_PSEUDO_REGISTER @minus{} 1}; thus, the first

Not OK.

> -if the array holds @code{-1}.
> +if the array holds @code{@minus{}1}.

Not OK.

> -log2(@var{VS})-1 bits of @var{addr} will be considered.
> +log2(@var{VS}) @minus{} 1 bits of @var{addr} will be considered.

OK.

> -or -1, if it doesn't.  @var{request} describes the type of requested
> +or @minus{}1, if it doesn't.  @var{request} describes the type of requested

OK.

> -@samp{REAL_VALUES_EQUAL (-0.0, 0.0)} is true, and
> +@samp{REAL_VALUES_EQUAL (@minus{}0.0, 0.0)} is true, and

Not OK.

> -like @code{unsigned ui = -1}; and conversions to smaller types, like
> +like @code{unsigned ui = @minus{}1}; and conversions to smaller types, like

Not OK.

> -((int) x)} and @code{ui = (unsigned) -1}, or if the value is not
> +((int) x)} and @code{ui = (unsigned) @minus{}1}, or if the value is not

Not OK.

> -and has length @code{((pc[-3]) & 0xff000000)}.
> +and has length @code{((pc[@minus{}3]) & 0xff000000)}.

Not OK.

> -Integer constant in the range -6 @dots{} 5.
> +Integer constant in the range @minus{}6 @dots{} 5.

OK.

> -Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
> +Constant that is one of @minus{}1, 4, @minus{}4, 7, 8, 12, 16, 20, 32, 48

OK.

> -Signed 16 bit integer (in the range -32768 to 32767)
> +Signed 16 bit integer (in the range @minus{}32768 to 32767)

OK.

> -Signed 7 bit integer (in the range -64 to 63)
> +Signed 7 bit integer (in the range @minus{}64 to 63)

OK.

> -Signed 4 bit integer (in the range -8 to 7)
> +Signed 4 bit integer (in the range @minus{}8 to 7)

OK.

> -Signed 3 bit integer (in the range -3 to 4)
> +Signed 3 bit integer (in the range @minus{}3 to 4)

OK.

> --8 @dots{} 7
> +@minus{}8 @dots{} 7

OK.

> --128 @dots{} 127
> +@minus{}128 @dots{} 127

OK.

> --32768 @dots{} 32767
> +@minus{}32768 @dots{} 32767

OK.

> --8 @dots{} -1 or 1 @dots{} 8
> +@minus{}8 @dots{} @minus{}1 or 1 @dots{} 8

OK.

> --16 @dots{} -1 or 1 @dots{} 16
> +@minus{}16 @dots{} @minus{}1 or 1 @dots{} 16

OK.

> --32 @dots{} -1 or 1 @dots{} 32
> +@minus{}32 @dots{} @minus{}1 or 1 @dots{} 32

OK.

> --65536 @dots{} -1
> +@minus{}65536 @dots{} @minus{}1

OK.

> -A constant in the range -65535 to -1 (inclusive).
> +A constant in the range @minus{}65535 to @minus{}1 (inclusive).

OK.

> -A constant in the range of 0 to -255.
> +A constant in the range of 0 to @minus{}255.

OK.

> -A constant in the range [-64, 63] for shift/rotate instructions.  
> +A constant in the range [@minus{}64, 63] for shift/rotate instructions.  

OK.

> -@item (-524288..524287)
> +@item (@minus{}524288..524287)

OK.

> -Expected size, when unknown, is set to @code{(const_int -1)}.
> +Expected size, when unknown, is set to @code{(const_int @minus{}1)}.

Not OK (I think textual RTL, in @code, should be considered like C to use 
HYPHEN-MINUS).

> -Expected size, when unknown, is set to @code{(const_int -1)}.
> +Expected size, when unknown, is set to @code{(const_int @minus{}1)}.

Not OK.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: RFA: Adding @minus{} to gcc documentation

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Hi Joseph,

> @minus{} should be used where what is being represented is a number, or 
> subtraction in English text, not when it is a piece of C source code.

Ah, OK.

So, do I have your approval to apply this revised patch ?

Cheers
   Nick

gcc/ChangeLog
2009-10-13  Nick Clifton  <nickc@redhat.com>


	* gcc/doc/extended.texi: Replace the dash character with
	@minus{} in situations where it is being used as a minus
	symbol.
	* gcc/doc/tm.texi: Likewise.
	* gcc/doc/invoke.texi: Likewise.
	* gcc/doc/md.texi: Likewise.

[-- Attachment #2: minus.patch --]
[-- Type: text/x-diff, Size: 5500 bytes --]

Index: gcc/doc/extend.texi
===================================================================
--- gcc/doc/extend.texi	(revision 152698)
+++ gcc/doc/extend.texi	(working copy)
@@ -935,7 +935,7 @@
 use it consistently in your program.
 
 Specifying @option{-mfp16-format=ieee} selects the IEEE 754-2008 format.
-This format can represent normalized values in the range of @math{2^{-14}} to 65504.
+This format can represent normalized values in the range of @math{2^{@minus{}14}} to 65504.
 There are 11 bits of significand precision, approximately 3
 decimal digits.
 
@@ -943,7 +943,7 @@
 alternative format.  This representation is similar to the IEEE
 format, but does not support infinities or NaNs.  Instead, the range
 of exponents is extended, so that this format can represent normalized
-values in the range of @math{2^{-14}} to 131008.
+values in the range of @math{2^{@minus{}14}} to 131008.
 
 The @code{__fp16} type is a storage format only.  For purposes
 of arithmetic and other operations, @code{__fp16} values in C or C++
@@ -9740,7 +9748,7 @@
 
 @item int __builtin_subs (int @var{x}, int @var{y})
 Saturating subtraction.  Return the result of subtracting @var{y} from
-@var{x}, storing the value -32768 if the result overflows.
+@var{x}, storing the value @minus{}32768 if the result overflows.
 
 @item void __builtin_halt (void)
 Halt.  The processor will stop execution.  This built-in is useful for
Index: gcc/doc/tm.texi
===================================================================
--- gcc/doc/tm.texi	(revision 152698)
+++ gcc/doc/tm.texi	(working copy)
@@ -5628,7 +5627,7 @@
 described above.
 If this hook is not defined, then @var{addr} will be used as
 the argument @var{OFF} to @code{REALIGN_LOAD}, in which case the low
-log2(@var{VS})-1 bits of @var{addr} will be considered.
+log2(@var{VS}) @minus{} 1 bits of @var{addr} will be considered.
 @end deftypefn
 
 @deftypefn {Target Hook} tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN (tree @var{x})
@@ -6610,7 +6618,7 @@
 The hook is used to check if the pattern of @var{insn} has a speculative
 version and, in case of successful check, to generate that speculative
 pattern.  The hook should return 1, if the instruction has a speculative form,
-or -1, if it doesn't.  @var{request} describes the type of requested
+or @minus{}1, if it doesn't.  @var{request} describes the type of requested
 speculation.  If the return value equals 1 then @var{new_pat} is assigned
 the generated speculative pattern.
 @end deftypefn
Index: gcc/doc/md.texi
===================================================================
--- gcc/doc/md.texi	(revision 152698)
+++ gcc/doc/md.texi	(working copy)
@@ -1756,7 +1756,7 @@
 A floating point constant 0.0
 
 @item R
-Integer constant in the range -6 @dots{} 5.
+Integer constant in the range @minus{}6 @dots{} 5.
 
 @item Q
 A memory address based on Y or Z pointer with displacement.
@@ -1787,7 +1787,7 @@
 Constant that fits in 5 bits
 
 @item L
-Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
+Constant that is one of @minus{}1, 4, @minus{}4, 7, 8, 12, 16, 20, 32, 48
 
 @item G
 Floating point constant that is legal for store immediate
@@ -2381,13 +2381,13 @@
 Any register except accumulators or CC.
 
 @item Ksh
-Signed 16 bit integer (in the range -32768 to 32767)
+Signed 16 bit integer (in the range @minus{}32768 to 32767)
 
 @item Kuh
 Unsigned 16 bit integer (in the range 0 to 65535)
 
 @item Ks7
-Signed 7 bit integer (in the range -64 to 63)
+Signed 7 bit integer (in the range @minus{}64 to 63)
 
 @item Ku7
 Unsigned 7 bit integer (in the range 0 to 127)
@@ -2396,10 +2396,10 @@
 Unsigned 5 bit integer (in the range 0 to 31)
 
 @item Ks4
-Signed 4 bit integer (in the range -8 to 7)
+Signed 4 bit integer (in the range @minus{}8 to 7)
 
 @item Ks3
-Signed 3 bit integer (in the range -3 to 4)
+Signed 3 bit integer (in the range @minus{}3 to 4)
 
 @item Ku3
 Unsigned 3 bit integer (in the range 0 to 7)
@@ -2511,28 +2511,28 @@
 Used to match function return values.
 
 @item Is3
--8 @dots{} 7
+@minus{}8 @dots{} 7
 
 @item IS1
--128 @dots{} 127
+@minus{}128 @dots{} 127
 
 @item IS2
--32768 @dots{} 32767
+@minus{}32768 @dots{} 32767
 
 @item IU2
 0 @dots{} 65535
 
 @item In4
--8 @dots{} -1 or 1 @dots{} 8
+@minus{}8 @dots{} @minus{}1 or 1 @dots{} 8
 
 @item In5
--16 @dots{} -1 or 1 @dots{} 16
+@minus{}16 @dots{} @minus{}1 or 1 @dots{} 16
 
 @item In6
--32 @dots{} -1 or 1 @dots{} 32
+@minus{}32 @dots{} @minus{}1 or 1 @dots{} 32
 
 @item IM2
--65536 @dots{} -1
+@minus{}65536 @dots{} @minus{}1
 
 @item Ilb
 An 8 bit value with exactly one bit set.
@@ -2717,7 +2717,7 @@
 or @code{ori}.
 
 @item N
-A constant in the range -65535 to -1 (inclusive).
+A constant in the range @minus{}65535 to @minus{}1 (inclusive).
 
 @item O
 A signed 15-bit constant.
@@ -2893,7 +2893,7 @@
 A constant in the range of 0 to 255.
 
 @item N
-A constant in the range of 0 to -255.
+A constant in the range of 0 to @minus{}255.
 
 @end table
 
@@ -3012,7 +3038,7 @@
 An immediate for the @code{iohl} instruction.  const_int is treated as a 32 bit value.  
 
 @item I
-A constant in the range [-64, 63] for shift/rotate instructions.  
+A constant in the range [@minus{}64, 63] for shift/rotate instructions.  
 
 @item J
 An unsigned 7-bit constant for conversion/nop/channel instructions.  
@@ -3083,7 +3109,7 @@
 @table @code
 @item (0..4095)
 for short displacement
-@item (-524288..524287)
+@item (@minus{}524288..524287)
 for long displacement
 @end table
 

Re: RFA: Adding @minus{} to gcc documentation

[Alfred M. Szmidt]

   Index: gcc/doc/extend.texi
   ===================================================================
   --- gcc/doc/extend.texi	(revision 152698)
   +++ gcc/doc/extend.texi	(working copy)
   @@ -935,7 +935,7 @@
    use it consistently in your program.

    Specifying @option{-mfp16-format=ieee} selects the IEEE 754-2008 format.
   -This format can represent normalized values in the range of @math{2^{-14}} to 65504.
   +This format can represent normalized values in the range of @math{2^{@minus{}14}} to 65504.
    There are 11 bits of significand precision, approximately 3
    decimal digits.

   @@ -943,7 +943,7 @@
    alternative format.  This representation is similar to the IEEE
    format, but does not support infinities or NaNs.  Instead, the range
    of exponents is extended, so that this format can represent normalized
   -values in the range of @math{2^{-14}} to 131008.
   +values in the range of @math{2^{@minus{}14}} to 131008.

Using @-commands inside @math tends to throw texinfo of is path, so
there is no need to use it there.  The formula will be formated
correctly by TeX.

Re: RFA: Adding @minus{} to gcc documentation

[Joseph S. Myers]

On Tue, 13 Oct 2009, Nick Clifton wrote:

> Hi Joseph,
> 
> > @minus{} should be used where what is being represented is a number, or
> > subtraction in English text, not when it is a piece of C source code.
> 
> Ah, OK.
> 
> So, do I have your approval to apply this revised patch ?

OK, subject to Alfred M. Szmidt's point about avoiding it inside @math{}.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: RFA: Add support for Renesas RX architecture to GCC (take 2)

[Nick Clifton]

Hi Richard,

> I think I mentioned this before -- IN_RANGE_P.

Yes you did.  I forgot.  Sorry.  One questions though: IN_RANGE_P is not
defined as a generic macro.  It seems that the backends that use it all
define their own, very similar versions.  Wouldn't it be simpler to use
the IN_RANGE macro defined in system.h instead ?  This is what I have
done in the new patch.


> Consider using e.g.
> 
>  (match_code "plus" "0")

Fascinating.  I was unaware of this feature of match_code.  Is it
documented somewhere ?


>> + static unsigned int
>> + bit_count (unsigned int x)
>> + {
>> +   const unsigned int m1 = 0x55555555;
>> +   const unsigned int m2 = 0x33333333;
>> +   const unsigned int m4 = 0x0f0f0f0f;
>> +
>> +   x -= (x >> 1) & m1;
>> +   x = (x & m2) + ((x >> 2) & m2);
>> +   x = (x + (x >> 4)) & m4;
>> +   x += x >>  8;
>> +
>> +   return (x + (x >> 16)) & 0x3f;
> 
> We should probably have this function moved to somewhere generic.  We 
> have several places within gcc that we compute a population count. 
> Search for popcount within the toplevel gcc sources.

Could I submit that as a separate patch ?  I would like to keep this one
RX specific.


>> +   ADD_RX_BUILTIN2 (TST,     "tst",     void,  intSI,  intSI);
> 
> One last cc0-setting builtin that isn't usable.

Yup.  Actually the btst builtin was also guilty of this sin.


>> +   ADD_RX_BUILTIN1 (PUSHC,   "pushc",   void,  integer);
>> +   ADD_RX_BUILTIN1 (POPC,    "popc",    void,  integer);
> 
> These are a bit questionable, seeing as how they manipulate the stack 
> register.  Consider either removing them, or having them force the 
> function to use a frame pointer?

I think that removing them would be the safest thing.  Even with a frame
pointer we cannot guarantee that the stack pointer will not be used for
addressing some things, so changing it underneath gcc's feet would be a
bad idea.



> Aren't there lots more addressing modes that are mode dependant?  E.g.
> 
>   (mem:QI (plus:SI (reg) (const_int 1)))
>   (mem:SI (plus:SI (reg) (const_int 131074)))
>   (mem:SI (plus:SI (mult:SI (reg) (const_int 4)))
> 
> I.e. the only addresses that aren't mode dependent are plain registers 
> and reg+const where const is a multiple of 4 and also small enough to 
> fit a byte offset.
> 
> Please move the contents of the macro into a function.

Done.

>> +     /* Control registers:  */         \
>> +   , { "psw",   0x0 }                  \
>> +   , { "pc",    0x1 }                  \
>> +   , { "usp",   0x2 }                  \
>> +   , { "fpsw",  0x3 }                  \
>> +   , { "bpsw",  0x8 }                  \
>> +   , { "bpc",   0x9 }                  \
>> +   , { "isp",   0xa }                  \
>> +   , { "fintv", 0xb }                  \
>> +   , { "intb",  0xc }                  \
> 
> These should not be in the same namespace with ADDITONAL_REGISTER_NAMES.

Done.

> All of your uses of match_parallel are incorrect.  You wind up 
> generating nested PARALLEL patterns.  The only thing that should be 
> present within a define_insn that uses it is a top-level match_parallel. 
>  This results in patterns like
> 
>  (define_insn "stack_pushm"
>     [(match_parallel 1 "rx_pushm_parallel"
>     [(set (reg:SI SP_REG)
>        (minus:SI (reg:SI SP_REG)
>              (match_operand:SI 0 "const_int_operand" "n")))])]
> 
> where the stack adjust is pushed inside of the parallel

Done.


> That's 'n' not 'i' since you can't negate symbol addresses. 

Done.

>  That said, 
> I'm not sure you should ever see a (minus reg const_int), since I'm 
> pretty sure we canonicalize on (plus reg const_int).

I thought so too, but I figured that it would not hurt to provide the
alternative in case there ever was a non-canonical case.


>> + (define_insn "addsf3"
>> +   [(set (match_operand:SF          0 "register_operand"  "=r,r,r")
>> +       (plus:SF (match_operand:SF 1 "register_operand"  "%0,0,0")
>> +                (match_operand:SF 2 "rx_source_operand"  "r,F,Q")))]
>> +   "! TARGET_64BIT_DOUBLES || fast_math_flags_set_p ()"
> 
> You took me literally with "-ffast-math" I see.  I really expected you 
> to de-couple -m64bit-double from -mieee.  I think -m64bit-double should 
> not affect SFmode *at all*.
> 
> Either you have a -mieee that disables the hw instructions that can't 
> handle subnormals, or you conditionalize all of these patterns on 
> flag_unsafe_math_optimizations only.  Although really one could argue 
> for a new flag -f{no-,}subnormal-math that's also adjusted by 
> -ffast-math instead.

Ah, OK, I think that I understand now.  I was unclear as to whether
defining DOUBLE_TYPE_SIZE to be the same as FLOAT_TYPE_SIZE would
automatically make DFmode the same as SFmode.


>> + ;; Byte swap (single 32-bit value).
>> + (define_insn "revl"
>> +   [(set (match_operand:SI           0 "register_operand" "+r")
>> +       (bswap:SI (match_operand:SI 1 "register_operand"  "r")))]
>> +   ""
>> +   "revl\t%1, %0"
>> +   [(set_attr "length" "3")]
>> + )
> 
> s/+/=/

Done.

>> + (define_insn "rolc"
>> + (define_insn "rorc"
>> + (define_insn "satr"
> 
> Depends on cc0, and so isn't reliable.

Done.

> I am moderately surprised that you aren't representing the accumulator 
> as a special hard register, kinda like the mips multiplier.

I probably should be.  This is only intended to be a base port and I was
not sure exactly how to describe an accumulator to gcc, so I left it
out.  Is this a deal-breaker ?  I would prefer to leave it out for now
and revisit this at a later date.


>> + (define_insn "round"
>> +   [(set (match_operand:SI                      0 "register_operand"  
>> "=r,r")
>> +       (unspec_volatile:SI [(match_operand:SF 1 "rx_compare_operand" 
>> "r,Q")]
>
> This should be lrintsf2.  And you really don't need the volatile.

Done.

>> + (define_insn "sync_lock_test_and_setsi"
>> +   [(parallel
> 
> Nested parallel; define_expand needs an explicit parallel, but 
> define_insn doesn't.

Done.

>> + (define_insn "xchg"
> 
> Why?  You've already got the sync pattern.

Historical - now removed.

Revised patch to follow.

Cheers
   Nick

Re: RFA: Add support for Renesas RX architecture to GCC (take 2)

[Joseph S. Myers]

On Thu, 15 Oct 2009, Nick Clifton wrote:

> > > + static unsigned int
> > > + bit_count (unsigned int x)
> > > + {
> > > +   const unsigned int m1 = 0x55555555;
> > > +   const unsigned int m2 = 0x33333333;
> > > +   const unsigned int m4 = 0x0f0f0f0f;
> > > +
> > > +   x -= (x >> 1) & m1;
> > > +   x = (x & m2) + ((x >> 2) & m2);
> > > +   x = (x + (x >> 4)) & m4;
> > > +   x += x >>  8;
> > > +
> > > +   return (x + (x >> 16)) & 0x3f;
> > 
> > We should probably have this function moved to somewhere generic.  We have
> > several places within gcc that we compute a population count. Search for
> > popcount within the toplevel gcc sources.
> 
> Could I submit that as a separate patch ?  I would like to keep this one
> RX specific.

If we create a generic population count function, it should use 
__builtin_popcount (or __builtin_popcountl for a count function of 
unsigned long) when built with GCC 3.4 or later (and should probably be 
inlined in a header in that case).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: RFA: Add support for Renesas RX architecture to GCC (take 2)

[Richard Henderson]

On 10/15/2009 06:01 AM, Joseph S. Myers wrote:
>
> If we create a generic population count function, it should use
> __builtin_popcount (or __builtin_popcountl for a count function of
> unsigned long) when built with GCC 3.4 or later (and should probably be
> inlined in a header in that case).

The couple of top-level uses do use the builtin, as that's how I found 
them.  I had thought we already had a generic function like exact_log2, 
but it turns out the top-level uses are more specific to the surrounding 
use.


r~

Re: RFA: Add support for Renesas RX architecture to GCC (take 2)

[Richard Henderson]

On 10/15/2009 01:13 AM, Nick Clifton wrote:
> Fascinating. I was unaware of this feature of match_code. Is it
> documented somewhere ?

Yes, in md.texi.  Though I see the manual is formatted badly here: look 
for MATCH_CODE instead of @code{match_code}.

>> We should probably have this function moved to somewhere generic. We
>> have several places within gcc that we compute a population count.
>> Search for popcount within the toplevel gcc sources.
>
> Could I submit that as a separate patch ? I would like to keep this one
> RX specific.

Yes.

>> I am moderately surprised that you aren't representing the accumulator
>> as a special hard register, kinda like the mips multiplier.
>
> I probably should be. This is only intended to be a base port and I was
> not sure exactly how to describe an accumulator to gcc, so I left it
> out. Is this a deal-breaker ? I would prefer to leave it out for now
> and revisit this at a later date.

No, it's not a deal-breaker.


r~