New port for TILEPro and TILE-Gx

New port for TILEPro and TILE-Gx

[Walter Lee]

On behalf of Tilera Corporation, I'd like to contribute gcc ports to two of its
families of architectures, the TILEPro architecture and the TILE-Gx
architecture.  TILEPro is a VLIW architecture with 32-bit registers, 32-bit
address space, and 64-bit instructions.  TILE-Gx is a VLIW architecture with
64-bit registers, 64-bit address space, and 64-bit instructions.  Both
architectures have load-store architecture ISAs.

The linux kernels for both architectures are actively supported on kernel.org.
Ports of binutils for both architectures have been approved for inclusion in
2.22.  We also have ports for libffi, glibc, and gdb that we plan to contribute
back.

More information on the architectures is available at
http://www.tilera.com/scm/docs/index.html.

I've run the gcc testsuites natively on both architectures, and can post such
results on gcc-testresults.  I've also verified that both targets compile
successfully with contrib/config-list.mk.

Tilera has completed the copyright assignment forms from FSF for gcc.

I would be the maintainer for both ports.

I'll be submitting the port in seven parts shortly:

1/7 toplevel changes
2/7 changes in contrib
3/7 gcc port
4/7 libcpp port
5/7 libgcc port
6/7 libgomp port
7/7 wwwdocs changes

Please let me know if I'm missing anything.

Thanks,

Walter Lee

[PATCH] New port for TILEPro and TILE-Gx 1/7: toplevel changes

[Walter Lee]

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

Here are the toplevel changes.

	* MAINTAINERS (tilegx port): Add self.
	(tilepro port): Add self.


[-- Attachment #2: TOP.diff --]
[-- Type: text/plain, Size: 641 bytes --]

diff -r -u -p -N /home/packages/gcc-4.7.0-179959/MAINTAINERS ./MAINTAINERS
--- /home/packages/gcc-4.7.0-179959/MAINTAINERS	2011-10-14 01:12:54.000000000 -0400
+++ ./MAINTAINERS	2011-10-14 18:14:11.075846000 -0400
@@ -102,6 +102,8 @@ sparc port		Eric Botcazou		ebotcazou@lib
 spu port		Trevor Smigiel		trevor_smigiel@playstation.sony.com
 spu port		David Edelsohn		dje.gcc@gmail.com
 spu port		Ulrich Weigand		uweigand@de.ibm.com
+tilegx port		Walter Lee		walt@tilera.com
+tilepro port		Walter Lee		walt@tilera.com
 v850 port		Nick Clifton		nickc@redhat.com
 vax port		Matt Thomas		matt@3am-software.com
 x86-64 port		Jan Hubicka		jh@suse.cz

[PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib

[Walter Lee]

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

Here are the contrib changes.

	* config-list.mk (tilegx-linux-gnu): Add.
	(tilepro-linux-gnu): Add.


[-- Attachment #2: contrib.diff --]
[-- Type: text/plain, Size: 897 bytes --]

diff -r -u -p -N /home/packages/gcc-4.7.0-179959/contrib/config-list.mk ./contrib/config-list.mk
--- /home/packages/gcc-4.7.0-179959/contrib/config-list.mk	2011-10-14 01:08:51.000000000 -0400
+++ ./contrib/config-list.mk	2011-10-14 18:14:11.064775000 -0400
@@ -59,7 +59,8 @@ LIST = alpha-linux-gnu alpha-freebsd6 al
   sparc-leon3-linux-gnuOPT-enable-target=all sparc-netbsdelf \
   sparc64-sun-solaris2.10OPT-with-gnu-ldOPT-with-gnu-asOPT-enable-threads=posix \
   sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux sparc64-freebsd6 \
-  sparc64-netbsd sparc64-openbsd spu-elf v850e-elf v850-elf vax-linux-gnu \
+  sparc64-netbsd sparc64-openbsd spu-elf tilegx-linux-gnu tilepro-linux-gnu \
+  v850e-elf v850-elf vax-linux-gnu \
   vax-netbsdelf vax-openbsd x86_64-apple-darwin \
   x86_64-pc-linux-gnuOPT-with-fpmath=avx \
   x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \

[PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port

[Walter Lee]

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

Here is the gcc port.

	* config.gcc: Handle tilegx and tilepro.
	* configure.ac (gcc_cv_as_dwarf2_debug_line): Enable test for
	tilegx and tilepro.
	Add HAVE_AS_TLS check for tilegx and tilepro.
	* configure: Regenerate.
	* doc/contrib.texi: Add Mat Hostetter and self.
	* doc/extend.texi (TILE-Gx Built-in Functions): New node.
	Document instruction intrinsics and network accessing intrinsics.
	(TILEPro Built-in Functions): New node.  Document instruction
	intrinsics and network accessing intrinsics.
	* doc/install.texi (Specific, tilegx-*-linux*): Document it.
	(Specific, tilepro-*-linux*): Likewise.
	* doc/invoke.texi (TILE-Gx Options): New section.
	(TILEPro Options): New section.
	* doc/md.texi (TILE-Gx): New section.
	(TILEPro): New section.
	* common/config/tilegx/tilegx-common.c: New file.
	* common/config/tilepro/tilepro-common.c: New file.
	* config/tilegx/constraints.md: New file.
	* config/tilegx/linux.h: New file.
	* config/tilegx/mul_tables.c: New file.
	* config/tilegx/predicates.md: New file.
	* config/tilegx/sync.md: New file.
	* config/tilegx/t-tilegx: New file.
	* config/tilegx/tilegx-builtins.h: New file.
	* config/tilegx/tilegx-c.c: New file.
	* config/tilegx/tilegx-generic.md: New file.
	* config/tilegx/tilegx-modes.def: New file.
	* config/tilegx/tilegx-multiply.h: New file.
	* config/tilegx/tilegx-protos.h: New file.
	* config/tilegx/tilegx.c: New file.
	* config/tilegx/tilegx.h: New file.
	* config/tilegx/tilegx.md: New file.
	* config/tilegx/tilegx.opt: New file.
	* config/tilepro/constraints.md: New file.
	* config/tilepro/linux.h: New file.
	* config/tilepro/mul_tables.c: New file.
	* config/tilepro/predicates.md: New file.
	* config/tilepro/t-tilepro: New file.
	* config/tilepro/tilepro-builtins.h: New file.
	* config/tilepro/tilepro-c.c: New file.
	* config/tilepro/tilepro-generic.md: New file.
	* config/tilepro/tilepro-modes.def: New file.
	* config/tilepro/tilepro-multiply.h: New file.
	* config/tilepro/tilepro-protos.h: New file.
	* config/tilepro/tilepro.c: New file.
	* config/tilepro/tilepro.h: New file.
	* config/tilepro/tilepro.md: New file.
	* config/tilepro/tilepro.opt: New file.

Here is a change to a test to handle the new targets.

	* testsuite/gcc.dg/20020312-2.c: Add a condition for
	__tile__.

[-- Attachment #2: gcc.diff.gz --]
[-- Type: application/x-gzip, Size: 231637 bytes --]

[-- Attachment #3: gcc_testsuite.diff --]
[-- Type: text/plain, Size: 545 bytes --]

diff -r -u -p -N /home/packages/gcc-4.7.0-179959/gcc/testsuite/gcc.dg/20020312-2.c ./gcc/testsuite/gcc.dg/20020312-2.c
--- /home/packages/gcc-4.7.0-179959/gcc/testsuite/gcc.dg/20020312-2.c	2011-10-14 00:57:27.000000000 -0400
+++ ./gcc/testsuite/gcc.dg/20020312-2.c	2011-10-14 18:14:11.138743000 -0400
@@ -64,6 +64,8 @@ extern void abort (void);
 # define PIC_REG  "12"
 #elif defined(__sparc__)
 # define PIC_REG  "l7"
+#elif defined(__tile__)
+# define PIC_REG "r51"
 #elif defined(__TMS320C6X__)
 # define PIC_REG "B14"
 #elif defined(__v850)

[PATCH] New port for TILEPro and TILE-Gx 4/7: libcpp port

[Walter Lee]

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

Here is the libcpp port.

	* configure.ac: Require 64-bit hwint for tilegx and tilepro.
	* configure: Regenerate.

[-- Attachment #2: libcpp.diff --]
[-- Type: text/plain, Size: 962 bytes --]

diff -r -u -p -N /home/packages/gcc-4.7.0-179959/libcpp/configure ./libcpp/configure
--- /home/packages/gcc-4.7.0-179959/libcpp/configure	2011-10-14 01:12:52.000000000 -0400
+++ ./libcpp/configure	2011-10-14 18:14:11.161721000 -0400
@@ -7320,7 +7320,8 @@ case $target in
 	s390*-*-* | \
 	sparc*-*-* | \
 	spu-*-* | \
-	sh[123456789lbe]*-*-* | sh-*-*)
+	sh[123456789lbe]*-*-* | sh-*-* | \
+	tilegx-*-* | tilepro-*-* )
 		need_64bit_hwint=yes ;;
 	*)
 		need_64bit_hwint=no ;;
diff -r -u -p -N /home/packages/gcc-4.7.0-179959/libcpp/configure.ac ./libcpp/configure.ac
--- /home/packages/gcc-4.7.0-179959/libcpp/configure.ac	2011-10-14 01:12:52.000000000 -0400
+++ ./libcpp/configure.ac	2011-10-14 18:14:11.141771000 -0400
@@ -158,7 +158,8 @@ case $target in
 	s390*-*-* | \
 	sparc*-*-* | \
 	spu-*-* | \
-	sh[123456789lbe]*-*-* | sh-*-*)
+	sh[123456789lbe]*-*-* | sh-*-* | \
+	tilegx-*-* | tilepro-*-* )
 		need_64bit_hwint=yes ;;
 	*)
 		need_64bit_hwint=no ;;

[PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port

[Walter Lee]

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

Here is the libgcc port.

	* config.host: Handle tilegx and tilepro.
	* config/tilegx/t-tilegx: New file.
	* config/tilepro/atomic.c: New file.
	* config/tilepro/milieu.h: New file.
	* config/tilepro/softdivide.c: New file.
	* config/tilepro/softfloat.c: New file.
	* config/tilepro/softfloat.h: New file.
	* config/tilepro/softfloat_macros.h: New file.
	* config/tilepro/softfloat_specialize.h: New file.
	* config/tilepro/softmpy.S: New file.
	* config/tilepro/softtile.h: New file.
	* config/tilepro/t-tilepro: New file.


[-- Attachment #2: libgcc.diff.gz --]
[-- Type: application/x-gzip, Size: 26917 bytes --]

[PATCH] New port for TILEPro and TILE-Gx: 6/7 libgomp port

[Walter Lee]

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

Here is the libgomp port.

	* configure.tgt: Handle tilegx and tilepro.
	* config/linux/tile/futex.h: New file.


[-- Attachment #2: libgomp.diff --]
[-- Type: text/plain, Size: 3148 bytes --]

diff -r -u -p -N /home/packages/gcc-4.7.0-179959/libgomp/config/linux/tile/futex.h ./libgomp/config/linux/tile/futex.h
--- /home/packages/gcc-4.7.0-179959/libgomp/config/linux/tile/futex.h	1969-12-31 19:00:00.000000000 -0500
+++ ./libgomp/config/linux/tile/futex.h	2011-10-14 18:14:11.657740000 -0400
@@ -0,0 +1,73 @@
+/* Copyright (C) 2011
+   Free Software Foundation, Inc.
+   Contributed by Walter Lee (walt@tilera.com)
+
+   This file is part of the GNU OpenMP Library (libgomp).
+
+   Libgomp is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   Libgomp is distributed in the hope that it will be useful, but WITHOUT ANY
+   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+   more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   <http://www.gnu.org/licenses/>.  */
+
+/* Provide target-specific access to the futex system call.  */
+
+#include <sys/syscall.h>
+#include <linux/futex.h>
+
+static inline void
+sys_futex0 (int *addr, int op, int val)
+{
+  long _sys_result;
+  long _clobber_r2, _clobber_r3, _clobber_r4, _clobber_r5, _clobber_r10;
+  int err;
+
+  __asm__ __volatile__ (
+    "swint1"
+    : "=R00" (_sys_result), "=R01" (err), "=R02" (_clobber_r2),
+      "=R03" (_clobber_r3), "=R04" (_clobber_r4), "=R05" (_clobber_r5),
+      "=R10" (_clobber_r10)
+    : "R10" (SYS_futex), "R00" (addr), "R01" (op), "R02" (val),
+      "R03" (0)
+    :  "r6",  "r7",
+       "r8",  "r9",        "r11", "r12", "r13", "r14", "r15",
+      "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
+      "r24", "r25", "r26", "r27", "r28", "r29", "memory");
+}
+
+static inline void
+futex_wait (int *addr, int val)
+{
+  sys_futex0 (addr, FUTEX_WAIT, val);
+}
+
+static inline void
+futex_wake (int *addr, int count)
+{
+  sys_futex0 (addr, FUTEX_WAKE, count);
+}
+
+static inline void
+cpu_relax (void)
+{
+  __asm volatile ("" : : : "memory");
+}
+
+static inline void
+atomic_write_barrier (void)
+{
+  __sync_synchronize ();
+}
diff -r -u -p -N /home/packages/gcc-4.7.0-179959/libgomp/configure.tgt ./libgomp/configure.tgt
--- /home/packages/gcc-4.7.0-179959/libgomp/configure.tgt	2011-10-14 00:46:46.000000000 -0400
+++ ./libgomp/configure.tgt	2011-10-14 18:14:11.167723000 -0400
@@ -51,6 +51,10 @@ if test $enable_linux_futex = yes; then
 	config_path="linux/s390 linux posix"
 	;;
 
+    tile*-*-linux*)
+	config_path="linux/tile linux posix"
+	;;
+
     # Note that bare i386 is not included here.  We need cmpxchg.
     i[456]86-*-linux*)
 	config_path="linux/x86 linux posix"

[PATCH] New port for TILEPro and TILE-Gx: 7/7 wwwdocs changes

[Walter Lee]

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

Here are the wwwdocs changes, with the news date TBD.


[-- Attachment #2: wwwdocs.diff --]
[-- Type: text/plain, Size: 2063 bytes --]

Index: backends.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.41
diff -u -p -r1.41 backends.html
--- backends.html	15 Jul 2011 09:48:14 -0000	1.41
+++ backends.html	15 Oct 2011 00:57:04 -0000
@@ -98,6 +98,8 @@ sh       |     Q   CB   qr      da   
 sparc    |     Q   CB   qr p    da   
 spu      |   ? Q  *C       p g bd    
 stormy16 | ???L  FIC D l   p  m  a
+tilegx   |   S Q   C    q  p g bda e
+tilepro  |   S   F C       p g bda e
 v850     | ??    FI       cp gm d   s
 vax      |  M?    I       cp     a e 
 xtensa   |   ?     C       p   bd    
Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.814
diff -u -p -r1.814 index.html
--- index.html	12 Oct 2011 04:48:22 -0000	1.814
+++ index.html	15 Oct 2011 00:57:04 -0000
@@ -53,6 +53,11 @@ mission statement</a>.</p>
 
 <dl class="news">
 
+<dt><span>TILE-Gx and TILEPro processor support</span>
+    <span class="date">[2011-??-??]</span></dt>
+<dd>Ports for the TILE-Gx and TILEPro families of processors have been
+contributed by Tilera.</dd>
+
 <dt><span>OpenMP v3.1</span>
     <span class="date">[2011-08-02]</span></dt>
 <dd>An implementation of the <a
Index: readings.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.215
diff -u -p -r1.215 readings.html
--- readings.html	15 Jul 2011 09:48:15 -0000	1.215
+++ readings.html	15 Oct 2011 00:57:04 -0000
@@ -257,6 +257,16 @@ Intel&reg;64 and IA-32 Architectures Sof
   <br />Acronym stands for: Scalable Processor ARChitecture
  </li>
  
+ <li>tilegx
+  <br />Manufacturer: Tilera
+  <br /><a href="http://www.tilera.com/scm/docs/index.html">Documentation</a>
+ </li>
+ 
+ <li>tilepro
+  <br />Manufacturer: Tilera
+  <br /><a href="http://www.tilera.com/scm/docs/index.html">Documentation</a>
+ </li>
+ 
  <li>v850
   <br />Manufacturer: NEC
  </li>

Re: [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port

[Joseph S. Myers]

All comments here refer to the first instance of an issue; many issues are 
shared between the two ports but are only mentioned once here.

On Sat, 15 Oct 2011, Walter Lee wrote:

> +#undef SYSROOT_SUFFIX_SPEC
> +#define SYSROOT_SUFFIX_SPEC "%{mbme:/usr/lib/bme;mnewlib:/usr/lib/newlib}"
> +
> +#undef SYSROOT_HEADERS_SUFFIX_SPEC
> +#define SYSROOT_HEADERS_SUFFIX_SPEC SYSROOT_SUFFIX_SPEC

These specs seem rather unusual.  Typically such specs would be generated 
depending on what multilibs were being built (see t-sysroot-suffix), and 
since a subdirectory sysroot itself contains directories such as usr/lib 
and usr/include, you would not expect a /usr/lib path within those specs.

It appears from the documentation that these are options for alternative C 
libraries.  There is an existing infrastructure for options for 
alternative C libraries used with the Linux kernel, with the -mbionic, 
-mglibc and -muclibc options all of which use Negative so that only the 
last one is considered for specs processing, all of which set a single 
variable and which affect the predefined macros, settings of 
TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS, etc.; you should integrate 
these options properly with that infrastructure.

But I don't see any sign of multilib settings to cause GCC's libraries to 
be built for these variants - although libstdc++, for example, definitely 
depends on libc in various ways, so you certainly can't expect to be able 
to use a different libc without having a separate multilib for it.

(I am presuming that these are for libraries used in userspace with the 
Linux kernel or as part of building the Linux kernel; if they aren't used 
with Linux at all then a separate -elf or -eabi target would be the normal 
approach.)

> +#undef ASM_SPEC
> +#define ASM_SPEC "%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} \
> + %{Wa,*:%*} %{m32:--32} %{m64:--64}"

All of this apart from %{m32:--32} %{m64:--64} is obsolete.  See a series 
of my patches that cleaned up obsolete pieces in specs.  
<http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00189.html> for -Wa,; 
<http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00192.html> for -n and -T; 
<http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00195.html> for -v; 
<http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00893.html> for -Yd,; 
<http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00913.html> for -Ym,; 
<http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00914.html> for -Qn and -Qy.

> +      %{!dynamic-linker:-dynamic-linker \

%{!dynamic-linker:...} doesn't do what you think and is also obsolete; 
again see my patches 
(<http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00194.html> in this case).

> +#undef  STARTFILE_SPEC
> +#define STARTFILE_SPEC "\
> +  %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \
> +  crti.o%s \
> +  %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s} \
> +  %{ffeedback-emit*:crtfbi.o%s}"

There are no -ffeedback-emit* or -ffeedback-generate options in FSF GCC so 
there should be no specs referencing them.

Without that, this looks identical to GNU_USER_TARGET_STARTFILE_SPEC in 
gnu-user.h so you shouldn't need to override that at all (but if you just 
need to add to it, then appeand to GNU_USER_TARGET_STARTFILE_SPEC rather 
than replicating its contents).

> +#undef  LIB_SPEC
> +#define LIB_SPEC \
> +  "%{ffeedback-generate*|ffeedback-emit*:-lgcov -linstr} \
> +   %{pthread:-lpthread} \
> +   %{shared:-lc} \
> +   %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}}"

You don't have a -mieee-fp option in your .opt file, so shouldn't have a 
spec for it.

> +#undef MCOUNT_NAME
> +#define MCOUNT_NAME "mcount"

For a new target it seems much better to define your ABI to use a name in 
the reserved namespace for this - that is, starting with two underscores.

> +/* For __clear_cache in libgcc2.c.  */
> +#ifdef IN_LIBGCC2
> +
> +#include <arch/icache.h>

Where does this header come from?  Linux kernel, glibc, somewhere else?  
In general you want to condition header includes on inhibit_libc to 
facilitate bootstrapping (including building a partial static libgcc) 
before the libc headers are installed, since configuring glibc to install 
its headers requires a working compiler to run configure tests.

> diff -r -u -p -N /home/packages/gcc-4.7.0-179959/gcc/config/tilegx/mul_tables.c ./gcc/config/tilegx/mul_tables.c
> --- /home/packages/gcc-4.7.0-179959/gcc/config/tilegx/mul_tables.c	1969-12-31 19:00:00.000000000 -0500
> +++ ./gcc/config/tilegx/mul_tables.c	2011-10-14 18:14:11.524757000 -0400
> @@ -0,0 +1,19853 @@

Are you really sure that this 19853-line file is source code - "the 
preferred form of the work for making modifications to it"?  How was it 
written?  If it was generated by a program, and modifying that program 
would be the preferred way of changing this file, then the genuine source 
code for that program needs to be included as well.  The genuine source 
code may not be used at build time - the ARM port has various code 
generated by O'Caml generators, for example - but at least it needs to be 
documented how someone, using the shipped source code and free software 
implementations of any relevant languages, can regenerate the generated 
file exactly.  And if the generation is easy and doesn't require unusual 
tools, the rules for doing so should go in the makefiles (if for whatever 
reason a generated file still needs shipping in the source tree, also 
update contrib/gcc_update to avoid accidental regeneration).

> +tilegx-c.o: $(srcdir)/config/tilegx/tilegx-c.c \
> +    $(CONFIG_H) $(SYSTEM_H) coretypes.h $(MACHMODE_H) \
> +    $(TM_H) $(TM_P_H) $(CPPLIB_H) $(TREE_H) $(C_COMMON_H)
> +	$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
> +	  $(srcdir)/config/tilegx/tilegx-c.c
> +
> +mul_tables.o: $(srcdir)/config/tilegx/mul_tables.c \
> +    $(CONFIG_H) $(SYSTEM_H) coretypes.h $(EXPR_H) $(OPTABS_H) \
> +    $(srcdir)/config/tilegx/tilegx-multiply.h
> +	$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
> +	  $(srcdir)/config/tilegx/mul_tables.c

When the compiler is built as C++, all source of the compiler should 
normally also be built as C++.  That is, you should use $(COMPILER), not 
$(CC).  You should also verify that if you build the compiler using a 
current trunk compiler as your starting point, it passes a 
--enable-werror-always build as both C and C++; if you have only tested 
with cross compiler builds rather than native bootstrap, those don't use 
-Werror by default, hence the need to test with --enable-werror-always and 
to use a recent trunk compiler as the starting point.

> +#ifndef _TILEGX_MULTIPLY_H
> +#define _TILEGX_MULTIPLY_H

Header include guards in host-side code like this should not be in the 
reserved namespace; use e.g. GCC_TILEGX_MULTIPLY_H instead.

> +#ifndef __TILEGX_PROTOS_H__
> +#define __TILEGX_PROTOS_H__

Likewise.

> +#include "errors.h"

errors.h is the header for cut-down diagnostic functions used in generator 
programs.  Normal compiler code should use diagnostic-core.h instead.

> +/* Implement TARGET_OPTION_OVERRIDE.  */
> +static void
> +tilegx_option_override (void)
> +{
> +  static const struct cpu_table {
> +    const char *const name;
> +    const enum processor_type processor;
> +  } cpu_table[] = {
> +    { "tilegx", PROCESSOR_TILEGX },
> +    { NULL, PROCESSOR_MAX }
> +  };
> +  const char *cpu_string;
> +  int i;
> +
> +  /* Default to TILE-GX.  */
> +  cpu_string = tilegx_cpu_string;
> +  if (cpu_string == NULL)
> +    cpu_string = "tilegx";
> +
> +  for (i = 0; cpu_table[i].name; i++)
> +    if (!strcmp (cpu_string, cpu_table[i].name))
> +      {
> +	tilegx_cpu = cpu_table[i].processor;
> +	break;
> +      }
> +
> +  if (!cpu_table[i].name)
> +    error ("bad value %s for -mcpu switch", cpu_string);

Is there a reason all this needs to use this hook rather than the generic 
.opt file Enum facility for options with enumerated arguments?

> +/* Return the simd variant of the constant NUM of mode MODE, by
> +   replicating it to fill an interger of mode DImode.  NUM is first
> +   truncated to fit in MODE.  */
> +rtx
> +tilegx_simd_int (rtx num, enum machine_mode mode)
> +{
> +  HOST_WIDE_INT n = 0;
> +
> +  if (CONST_INT_P (num))
> +    {
> +      n = INTVAL (num);
> +    }
> +  else
> +    {
> +      error ("Immediate operand to SIMD op not a constant.");
> +    }

Error messages should not start with a capital letter or end with '.'.

Is this a message about a bad argument to a built-in function, or 
something like that?  If not (if no input should ever generate it), then 
I'd think it should be an internal error, not a normal one.  But if it 
does come from built-in expansion then this point is probably too late to 
get a good diagnostic location; ideally you'd use error_at with a location 
derived from the relevant expression, and generate errors early enough for 
that to be possible.

> +    if (!(*insn_op->predicate) (op[opnum], insn_op->mode))
> +      {
> +	/* We still failed to meet the predicate even after moving
> +	   into a register. Assume we needed an immediate.  */
> +	error ("operand must be an immediate of the right size");

Here's another case where explicit locations would be better.  You may at 
least be able to check EXPR_HAS_LOCATION (exp) and use the expression's 
location if so.

> +	  output_operand_lossage ("Invalid operand for 'r' specifier.");

Again, diagnostics should not start with an uppercase letter or end with a 
period.

> +@smallexample
> +
> +unsigned long long __insn_op (...)
> +
> +@end smallexample
> +
> +Where ``op'' is the name of the instruction.  Refer to the ISA manual
> +for the complete list of instructions.

Should use @var{op} in both the example and in the main text in place of 
``op''.

> +tilegx-*-linux*)
> +	tm_file="elfos.h gnu-user.h linux.h glibc-stdint.h tilegx/linux.h ${tm_file}"
> +        tmake_file="${tmake_file} tilegx/t-tilegx"
> +	extra_headers="tilegx-builtins.h tilegx-multiply.h"
> +	extra_objs="mul_tables.o"
> +	c_target_objs="tilegx-c.o"
> +	cxx_target_objs="tilegx-c.o"
> +	;;
> +tilepro-*-linux*)
> +	tm_file="elfos.h gnu-user.h linux.h glibc-stdint.h tilepro/linux.h ${tm_file}"
> +        tmake_file="${tmake_file} tilepro/t-tilepro"
> +	extra_headers="tilepro-builtins.h tilepro-multiply.h"

extra_headers is for headers for the *target*, that should be installed 
with the compiler and should have the runtime library license exception, 
not for headers that are part of the compiler on the *host*.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port

[Joseph S. Myers]

On Sat, 15 Oct 2011, Walter Lee wrote:

> +FPBIT_FUNCS := $(filter-out \
> +  _addsub_sf _mul_sf _div_sf _negate_sf \
> +  _eq_sf _ne_sf _le_sf _lt_sf _ge_sf _gt_sf \
> +  _sf_to_di _sf_to_si _sf_to_udi _sf_do_usi \
> +  _di_to_sf _si_to_sf _udi_to_sf _usi_to_sf, \
> +  $(FPBIT_FUNCS))
> +
> +DPBIT_FUNCS := $(filter-out \
> +  _addsub_df _mul_df _div_df _negate_df \
> +  _eq_df _ne_df _le_df _lt_df _ge_df _gt_df \
> +  _df_to_di _df_to_si _df_to_udi _df_do_usi \
> +  _di_to_df _si_to_df _udi_to_df _usi_to_df, \
> +  $(DPBIT_FUNCS))

I'm not clear on quite why you are enabling fpbit at all if you then 
disable most of the functions from it.  What functions do you actually 
still get from fpbit, how are they used and would it be better to have 
separate implementations of them?

How does the implementation you have used compare in performance with (a) 
fpbit and (b) soft-fp?  (If you have access to EEMBC, that's quite good as 
a benchmark of software floating-point performance; see the paper in the 
2006 GCC Summit proceedings; other floating-point-heavy benchmarks could 
probably be used as well.)  Since you have two architectures, one of which 
has both 32-bit and 64-bit variants, benchmarks should probably be given 
for all three cases.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] New port for TILEPro and TILE-Gx: 7/7 wwwdocs changes

[Gerald Pfeifer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 164 bytes --]

On Sat, 15 Oct 2011, Walter Lee wrote:
> Here are the wwwdocs changes, with the news date TBD.

This is approved (once the actual code has gone in).

Thanks,
Gerald

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2063 bytes --]

Index: backends.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.41
diff -u -p -r1.41 backends.html
--- backends.html	15 Jul 2011 09:48:14 -0000	1.41
+++ backends.html	15 Oct 2011 00:57:04 -0000
@@ -98,6 +98,8 @@ sh       |     Q   CB   qr      da   
 sparc    |     Q   CB   qr p    da   
 spu      |   ? Q  *C       p g bd    
 stormy16 | ???L  FIC D l   p  m  a
+tilegx   |   S Q   C    q  p g bda e
+tilepro  |   S   F C       p g bda e
 v850     | ??    FI       cp gm d   s
 vax      |  M?    I       cp     a e 
 xtensa   |   ?     C       p   bd    
Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.814
diff -u -p -r1.814 index.html
--- index.html	12 Oct 2011 04:48:22 -0000	1.814
+++ index.html	15 Oct 2011 00:57:04 -0000
@@ -53,6 +53,11 @@ mission statement</a>.</p>
 
 <dl class="news">
 
+<dt><span>TILE-Gx and TILEPro processor support</span>
+    <span class="date">[2011-??-??]</span></dt>
+<dd>Ports for the TILE-Gx and TILEPro families of processors have been
+contributed by Tilera.</dd>
+
 <dt><span>OpenMP v3.1</span>
     <span class="date">[2011-08-02]</span></dt>
 <dd>An implementation of the <a
Index: readings.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.215
diff -u -p -r1.215 readings.html
--- readings.html	15 Jul 2011 09:48:15 -0000	1.215
+++ readings.html	15 Oct 2011 00:57:04 -0000
@@ -257,6 +257,16 @@ Intel&reg;64 and IA-32 Architectures Sof
   <br />Acronym stands for: Scalable Processor ARChitecture
  </li>
  
+ <li>tilegx
+  <br />Manufacturer: Tilera
+  <br /><a href="http://www.tilera.com/scm/docs/index.html">Documentation</a>
+ </li>
+ 
+ <li>tilepro
+  <br />Manufacturer: Tilera
+  <br /><a href="http://www.tilera.com/scm/docs/index.html">Documentation</a>
+ </li>
+ 
  <li>v850
   <br />Manufacturer: NEC
  </li>

Re: [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port

[Walter Lee]

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

Hi Joseph,

Thanks for the feedback.  I am attaching a gcc patch that addresses most 
of the comments.  Here are replies to a few of the comments:

> > +#undef SYSROOT_SUFFIX_SPEC
> > +#define SYSROOT_SUFFIX_SPEC "%{mbme:/usr/lib/bme;mnewlib:/usr/lib/newlib}"
> > +
> > +#undef SYSROOT_HEADERS_SUFFIX_SPEC
> > +#define SYSROOT_HEADERS_SUFFIX_SPEC SYSROOT_SUFFIX_SPEC
>
> These specs seem rather unusual.  Typically such specs would be generated
> depending on what multilibs were being built (see t-sysroot-suffix), and
> since a subdirectory sysroot itself contains directories such as usr/lib
> and usr/include, you would not expect a /usr/lib path within those specs.

I've reverted the SYSROOT changes to support -mbme and -mnewlib for now.

> > +#undef MCOUNT_NAME
> > +#define MCOUNT_NAME "mcount"
>
> For a new target it seems much better to define your ABI to use a name in
> the reserved namespace for this - that is, starting with two underscores.

I've changed it to use "_mcount" with one underscore.  That seems to be 
what glibc support by default, and it's consistent with x86, and we'd 
prefer to be consistent with x86 whenever possible.

> > +/* For __clear_cache in libgcc2.c.  */
> > +#ifdef IN_LIBGCC2
> > +
> > +#include <arch/icache.h>
>
> Where does this header come from?  Linux kernel, glibc, somewhere else?
> In general you want to condition header includes on inhibit_libc to
> facilitate bootstrapping (including building a partial static libgcc)
> before the libc headers are installed, since configuring glibc to install
> its headers requires a working compiler to run configure tests.

We plan to include this as part of the Linux kernel, as the kernel 
itself depends on it.

> > diff -r -u -p -N /home/packages/gcc-4.7.0-179959/gcc/config/tilegx/mul_tables.c ./gcc/config/tilegx/mul_tables.c
> > --- /home/packages/gcc-4.7.0-179959/gcc/config/tilegx/mul_tables.c    1969-12-31 19:00:00.000000000 -0500
> > +++ ./gcc/config/tilegx/mul_tables.c  2011-10-14 18:14:11.524757000 -0400
> > @@ -0,0 +1,19853 @@
>
> Are you really sure that this 19853-line file is source code - "the
> preferred form of the work for making modifications to it"?  How was it
> written?

I've included the source code from which the tables are generated, and 
I've updated the makefiles with rules to generate the tables.  The 
script takes a minute to run, so I'd prefer not to generate it for every 
build, so I've kept the generated taables as part of the patch and 
updated the gcc_update script accordingly.

> You should also verify that if you build the compiler using a current
> trunk compiler as your starting point, it passes a
> --enable-werror-always build as both C and C++

I've verified this condition using the config-list.mk script.

Thanks,

Walter

	* config.gcc: Handle tilegx and tilepro.
	* configure.ac (gcc_cv_as_dwarf2_debug_line): Enable test for
	tilegx and tilepro.
	Add HAVE_AS_TLS check for tilegx and tilepro.
	* configure: Regenerate.
	* doc/contrib.texi: Add Mat Hostetter and self.
	* doc/extend.texi (TILE-Gx Built-in Functions): New node.
	Document instruction intrinsics and network accessing intrinsics.
	(TILEPro Built-in Functions): New node.  Document instruction
	intrinsics and network accessing intrinsics.
	* doc/install.texi (Specific, tilegx-*-linux*): Document it.
	(Specific, tilepro-*-linux*): Likewise.
	* doc/invoke.texi (TILE-Gx Options): New section.
	(TILEPro Options): New section.
	* doc/md.texi (TILE-Gx): New section.
	(TILEPro): New section.
	* common/config/tilegx/tilegx-common.c: New file.
	* common/config/tilepro/tilepro-common.c: New file.
	* config/tilegx/constraints.md: New file.
	* config/tilegx/linux.h: New file.
	* config/tilegx/mul-tables.c: New file.
	* config/tilegx/predicates.md: New file.
	* config/tilegx/sync.md: New file.
	* config/tilegx/t-tilegx: New file.
	* config/tilegx/tilegx-builtins.h: New file.
	* config/tilegx/tilegx-c.c: New file.
	* config/tilegx/tilegx-generic.md: New file.
	* config/tilegx/tilegx-modes.def: New file.
	* config/tilegx/tilegx-multiply.h: New file.
	* config/tilegx/tilegx-protos.h: New file.
	* config/tilegx/tilegx.c: New file.
	* config/tilegx/tilegx.h: New file.
	* config/tilegx/tilegx.md: New file.
	* config/tilegx/tilegx.opt: New file.
	* config/tilepro/constraints.md: New file.
	* config/tilepro/gen-mul-tables.cc: New file.
	* config/tilepro/linux.h: New file.
	* config/tilepro/mul-tables.c: New file.
	* config/tilepro/predicates.md: New file.
	* config/tilepro/t-tilepro: New file.
	* config/tilepro/tilepro-builtins.h: New file.
	* config/tilepro/tilepro-c.c: New file.
	* config/tilepro/tilepro-generic.md: New file.
	* config/tilepro/tilepro-modes.def: New file.
	* config/tilepro/tilepro-multiply.h: New file.
	* config/tilepro/tilepro-protos.h: New file.
	* config/tilepro/tilepro.c: New file.
	* config/tilepro/tilepro.h: New file.
	* config/tilepro/tilepro.md: New file.
	* config/tilepro/tilepro.opt: New file.

The gcc testsuite change is the same as before.

	* testsuite/gcc.dg/20020312-2.c: Add a condition for
	__tile__.



[-- Attachment #2: gcc.diff.gz --]
[-- Type: application/x-gzip, Size: 254624 bytes --]

[-- Attachment #3: gcc_testsuite.diff --]
[-- Type: text/plain, Size: 545 bytes --]

diff -r -u -p -N /home/packages/gcc-4.7.0-180241/gcc/testsuite/gcc.dg/20020312-2.c ./gcc/testsuite/gcc.dg/20020312-2.c
--- /home/packages/gcc-4.7.0-180241/gcc/testsuite/gcc.dg/20020312-2.c	2011-10-14 00:57:27.000000000 -0400
+++ ./gcc/testsuite/gcc.dg/20020312-2.c	2011-10-20 10:23:51.377473000 -0400
@@ -64,6 +64,8 @@ extern void abort (void);
 # define PIC_REG  "12"
 #elif defined(__sparc__)
 # define PIC_REG  "l7"
+#elif defined(__tile__)
+# define PIC_REG "r51"
 #elif defined(__TMS320C6X__)
 # define PIC_REG "B14"
 #elif defined(__v850)

Re: [PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib

[Walter Lee]

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

Here is a resubmission of the contrib patch, adding the entries to
gcc_update to handle the multiply tables.

	* config-list.mk (tilegx-linux-gnu): Add.
	(tilepro-linux-gnu): Add.
         * gcc_update (gcc/config/tilegx/mul-tables.c): New dependencies.
	(gcc/config/tilepro/mul-tables.c): New dependencies.

[-- Attachment #2: contrib.diff --]
[-- Type: text/plain, Size: 1802 bytes --]

diff -r -u -p -N /home/packages/gcc-4.7.0-180241/contrib/config-list.mk ./contrib/config-list.mk
--- /home/packages/gcc-4.7.0-180241/contrib/config-list.mk	2011-10-14 01:08:51.000000000 -0400
+++ ./contrib/config-list.mk	2011-10-20 10:23:51.331484000 -0400
@@ -59,7 +59,8 @@ LIST = alpha-linux-gnu alpha-freebsd6 al
   sparc-leon3-linux-gnuOPT-enable-target=all sparc-netbsdelf \
   sparc64-sun-solaris2.10OPT-with-gnu-ldOPT-with-gnu-asOPT-enable-threads=posix \
   sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux sparc64-freebsd6 \
-  sparc64-netbsd sparc64-openbsd spu-elf v850e-elf v850-elf vax-linux-gnu \
+  sparc64-netbsd sparc64-openbsd spu-elf tilegx-linux-gnu tilepro-linux-gnu \
+  v850e-elf v850-elf vax-linux-gnu \
   vax-netbsdelf vax-openbsd x86_64-apple-darwin \
   x86_64-pc-linux-gnuOPT-with-fpmath=avx \
   x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \
diff -r -u -p -N /home/packages/gcc-4.7.0-180241/contrib/gcc_update ./contrib/gcc_update
--- /home/packages/gcc-4.7.0-180241/contrib/gcc_update	2011-10-14 01:08:51.000000000 -0400
+++ ./contrib/gcc_update	2011-10-20 10:23:51.337478000 -0400
@@ -88,6 +88,8 @@ gcc/config/c6x/c6x-mult.md: gcc/config/c
 gcc/config/m68k/m68k-tables.opt: gcc/config/m68k/m68k-devices.def gcc/config/m68k/m68k-isas.def gcc/config/m68k/m68k-microarchs.def gcc/config/m68k/genopt.sh
 gcc/config/mips/mips-tables.opt: gcc/config/mips/mips-cpus.def gcc/config/mips/genopt.sh
 gcc/config/rs6000/rs6000-tables.opt: gcc/config/rs6000/rs6000-cpus.def gcc/config/rs6000/genopt.sh
+gcc/config/tilegx/mul-tables.c: gcc/config/tilepro/gen-mul-tables.cc
+gcc/config/tilepro/mul-tables.c: gcc/config/tilepro/gen-mul-tables.cc
 # And then, language-specific files
 gcc/cp/cfns.h: gcc/cp/cfns.gperf
 gcc/java/keyword.h: gcc/java/keyword.gperf

Re: [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port

[Walter Lee]

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

Here is a resubmission of the libgcc patch, using soft-fp as the 
floating point library.  I plan to do the benchmarking between the 
implementations as suggested, but I'd like to decouple that from the 
initial submission.

	* config.host: Handle tilegx and tilepro.
	* config/tilegx/sfp-machine.h: New file.
	* config/tilegx/sfp-machine32.h: New file.
	* config/tilegx/sfp-machine64.h: New file.
	* config/tilegx/t-softfp: New file.
	* config/tilegx/t-tilegx: New file.
	* config/tilepro/atomic.c: New file.
	* config/tilepro/sfp-machine.h: New file.
	* config/tilepro/softdivide.c: New file.
	* config/tilepro/softmpy.S: New file.
	* config/tilepro/t-tilepro: New file.


[-- Attachment #2: libgcc.diff.gz --]
[-- Type: application/x-gzip, Size: 6338 bytes --]

Re: [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port

[Joseph S. Myers]

On Thu, 20 Oct 2011, Walter Lee wrote:

> > > +#undef MCOUNT_NAME
> > > +#define MCOUNT_NAME "mcount"
> > 
> > For a new target it seems much better to define your ABI to use a name in
> > the reserved namespace for this - that is, starting with two underscores.
> 
> I've changed it to use "_mcount" with one underscore.  That seems to be what
> glibc support by default, and it's consistent with x86, and we'd prefer to be
> consistent with x86 whenever possible.

x86 also has a newer version __fentry__ with -mfentry.  ARM has mcount and 
__gnu_mcount_nc.  I don't think consistency with the old x86 _mcount is 
particularly desirable.

> > > +/* For __clear_cache in libgcc2.c.  */
> > > +#ifdef IN_LIBGCC2
> > > +
> > > +#include <arch/icache.h>
> > 
> > Where does this header come from?  Linux kernel, glibc, somewhere else?
> > In general you want to condition header includes on inhibit_libc to
> > facilitate bootstrapping (including building a partial static libgcc)
> > before the libc headers are installed, since configuring glibc to install
> > its headers requires a working compiler to run configure tests.
> 
> We plan to include this as part of the Linux kernel, as the kernel itself
> depends on it.

So "make headers_install" for your architectures will install this header 
under than name?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port

[Walter Lee]

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

On 10/20/2011 4:07 PM, Joseph S. Myers wrote:
> x86 also has a newer version __fentry__ with -mfentry.  ARM has mcount and 
> __gnu_mcount_nc.  I don't think consistency with the old x86 _mcount is 
> particularly desirable.

Ok attached is a new patch that uses "__mcount."

>> We plan to include this as part of the Linux kernel, as the kernel itself
>> depends on it.
> 
> So "make headers_install" for your architectures will install this header 
> under than name?

Yes.  We've made that change in linux and will be pushing that change upstream
shortly.

Walter

	
	* config.gcc: Handle tilegx and tilepro.
	* configure.ac (gcc_cv_as_dwarf2_debug_line): Enable test for
	tilegx and tilepro.
	Add HAVE_AS_TLS check for tilegx and tilepro.
	* configure: Regenerate.
	* doc/contrib.texi: Add Mat Hostetter and self.
	* doc/extend.texi (TILE-Gx Built-in Functions): New node.
	Document instruction intrinsics and network accessing intrinsics.
	(TILEPro Built-in Functions): New node.  Document instruction
	intrinsics and network accessing intrinsics.
	* doc/install.texi (Specific, tilegx-*-linux*): Document it.
	(Specific, tilepro-*-linux*): Likewise.
	* doc/invoke.texi (TILE-Gx Options): New section.
	(TILEPro Options): New section.
	* doc/md.texi (TILE-Gx): New section.
	(TILEPro): New section.
	* common/config/tilegx/tilegx-common.c: New file.
	* common/config/tilepro/tilepro-common.c: New file.
	* config/tilegx/constraints.md: New file.
	* config/tilegx/linux.h: New file.
	* config/tilegx/mul-tables.c: New file.
	* config/tilegx/predicates.md: New file.
	* config/tilegx/sync.md: New file.
	* config/tilegx/t-tilegx: New file.
	* config/tilegx/tilegx-builtins.h: New file.
	* config/tilegx/tilegx-c.c: New file.
	* config/tilegx/tilegx-generic.md: New file.
	* config/tilegx/tilegx-modes.def: New file.
	* config/tilegx/tilegx-multiply.h: New file.
	* config/tilegx/tilegx-protos.h: New file.
	* config/tilegx/tilegx.c: New file.
	* config/tilegx/tilegx.h: New file.
	* config/tilegx/tilegx.md: New file.
	* config/tilegx/tilegx.opt: New file.
	* config/tilepro/constraints.md: New file.
	* config/tilepro/gen-mul-tables.cc: New file.
	* config/tilepro/linux.h: New file.
	* config/tilepro/mul-tables.c: New file.
	* config/tilepro/predicates.md: New file.
	* config/tilepro/t-tilepro: New file.
	* config/tilepro/tilepro-builtins.h: New file.
	* config/tilepro/tilepro-c.c: New file.
	* config/tilepro/tilepro-generic.md: New file.
	* config/tilepro/tilepro-modes.def: New file.
	* config/tilepro/tilepro-multiply.h: New file.
	* config/tilepro/tilepro-protos.h: New file.
	* config/tilepro/tilepro.c: New file.
	* config/tilepro/tilepro.h: New file.
	* config/tilepro/tilepro.md: New file.
	* config/tilepro/tilepro.opt: New file.

[-- Attachment #2: gcc.diff.gz --]
[-- Type: application/x-gzip, Size: 254628 bytes --]

Re: [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port

[Walter Lee]

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

Here is a resubmission of the libgcc patch, removing the dependence on a header
(arch/atomic.h) that's not installed by linux.

Walter

	* config.host: Handle tilegx and tilepro.
	* config/tilegx/sfp-machine.h: New file.
	* config/tilegx/sfp-machine32.h: New file.
	* config/tilegx/sfp-machine64.h: New file.
	* config/tilegx/t-softfp: New file.
	* config/tilegx/t-tilegx: New file.
	* config/tilepro/atomic.c: New file.
	* config/tilepro/atomic.h: New file.
	* config/tilepro/sfp-machine.h: New file.
	* config/tilepro/softdivide.c: New file.
	* config/tilepro/softmpy.S: New file.
	* config/tilepro/t-tilepro: New file.


[-- Attachment #2: libgcc.diff.gz --]
[-- Type: application/x-gzip, Size: 11777 bytes --]

[PING] New port for TILEPro and TILE-Gx

[Walter Lee]

Ping?  I believe I have addressed all the reviewer's (namely Joseph Myers')
comments to date.

Thanks,

Walter Lee

Re: [PING2] New port for TILEPro and TILE-Gx

[Walter Lee]

Seeking more feedback or status update.

Thanks,

Walter Lee

On 10/30/2011 12:07 PM, Walter Lee wrote:
> Ping?  I believe I have addressed all the reviewer's (namely Joseph Myers')
> comments to date.
> 
> Thanks,
> 
> Walter Lee

Re: [PING2] New port for TILEPro and TILE-Gx

[Richard Henderson]

On 11/07/2011 08:59 AM, Walter Lee wrote:
> Seeking more feedback or status update.
> 
> Thanks,
> 
> Walter Lee
> 
> On 10/30/2011 12:07 PM, Walter Lee wrote:
>> Ping?  I believe I have addressed all the reviewer's (namely Joseph Myers')
>> comments to date.

I haven't seen a re-post since Joseph's review?
If I've missed it, please give me urls into the gcc-patches archive.


r~

Re: [PING2] New port for TILEPro and TILE-Gx

[Walter Lee]

On 11/7/2011 5:17 PM, Richard Henderson wrote:
> I haven't seen a re-post since Joseph's review?
> If I've missed it, please give me urls into the gcc-patches archive.

contrib:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01881.html

gcc:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01880.html
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02084.html

libgcc:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01882.html
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02086.html

Thanks,

Walter Lee

Re: [PING2] New port for TILEPro ...

[Richard Henderson]

On 11/07/2011 03:28 PM, Walter Lee wrote:
> gcc:
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02084.html

Well, I must say I'm a bit disappointed that the two ports 
are just dis-similar enough to not be merged.  And failing
that, I'd prefer to review them separately.

Tilepro:

>   (UNSPEC_INSN_ADDB                    1)
>   (UNSPEC_INSN_ADDBS_U                 2)
>   (UNSPEC_INSN_ADDH                    3)
>   (UNSPEC_INSN_ADDHS                   4)
>   (UNSPEC_INSN_ADDIB                   5)
>   (UNSPEC_INSN_ADDIH                   6)

All of these really ought to be re-written using proper rtl.
For instance, 

> (define_insn "insn_addb"
>   [(set (match_operand:SI 0 "register_operand" "=r,r")
>         (unspec:SI [(match_operand:SI 1 "reg_or_0_operand" "%rO,rO")
>                     (match_operand:SI 2 "reg_or_cint_operand" "N,rO")] 
>                    UNSPEC_INSN_ADDB))]
>   ""
>   "@
>    addib\t%0, %r1, %j2
>    addb\t%0, %r1, %r2"
>   [(set_attr "type" "X01,X01")])

ought to be

(define_insn "addv4qi3"
  [(set (match_operand:V4QI 0 "register_operand" "=r,r")
	(plus:V4QI (match_operand:V4QI 1 "reg_or_0_operand" "%rO,rO")
		   (match_operand:V4QI 2 "reg_or_cint_operand" "N,rO")))]
  ...)

Similarly, addbs_u should be usaddv4qi3 using (us_plus:V4QI ...),
addh should be (plus:V2HI ...), and so forth throughout most of the
unspecs present in the file.

As it is, you're making absolutely no use of the vectorizer.

> (define_insn "*movqi_insn"
>   [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,r,r,m")
>         (match_operand:QI 1 "move_operand"         "r,I,J,K,m,rO"))]
>   "(register_operand (operands[0], QImode)
>     || reg_or_0_operand (operands[1], QImode))"
>   "@
>    move\t%0, %r1
>    movei\t%0, %1
>    moveli\t%0, %1
>    auli\t%0, zero, %h1

Alternatives 1,2,3 are dead code -- there will never be a QImode constant in those ranges.
Similarly for movhi_insn and alternative 3.

> (define_insn_and_split "*movsi_big_immediate"
>   [(set (match_operand:SI 0 "register_operand" "=r")
>         (match_operand:SI 1 "immediate_operand" "i"))]
>   "! move_operand (operands[1], SImode)"
>   "#"
>   "&& 1"
>   [(const_int 0)]
> {
>   tilepro_expand_set_const32 (operands[0], operands[1]);
>   DONE;
> })

Why?  Seems like the movsi expander would handle this.  If you provide the
pattern, it'll get used.  Which will cause the rtl optimizers to undo this
split any chance they get.

> (define_expand "movdi"
>   [(set (match_operand:DI 0 "nonimmediate_operand" "")
>         (match_operand:DI 1 "general_operand" ""))]
>   ""
> {
>   if (tilepro_expand_mov (DImode, operands))
>     DONE;
> })
> 
> (define_insn_and_split "*movdi_insn"
>   [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,m")
>         (match_operand:DI 1 "general_operand" "i,rO,rO"))]
>   "!MEM_P (operands[0]) || REG_P (operands[1])"
>   "#"
>   ; We need a temp reg for addr+4 for the store, so we can't do this late.
>   "!MEM_P (operands[0]) || can_create_pseudo_p()"
>   [(set (match_dup 2) (match_dup 3))
>    (set (match_dup 4) (match_dup 5))]

I strongly suggest that you drop this pattern and let the rtl optimizers
split the multi-word move.

> (define_insn "movstrictqi"
>   [(set (strict_low_part (match_operand:QI 0 "register_operand" "+r"))
>         (match_operand:QI 1 "reg_or_0_operand" "rO"))]
>   ""
>   "mm\t%r0, %r1, %r0, 0, 7"
>   [(set_attr "type" "X01")])
>   
> (define_insn "movstricthi"
>   [(set (strict_low_part (match_operand:HI 0 "register_operand" "+r"))
>         (match_operand:HI 1 "reg_or_0_operand" "rO"))]
>   ""
>   "mm\t%r0, %r1, %r0, 0, 15"
>   [(set_attr "type" "X01")])

Do you really get any advantage over a more canonical expansion of insv?
Or, rather, an insv internal patterns such as

(define_insn "*insv_0"
  [(set (zero_extract:SI
	 (match_operand:SI 0 "register_operand" "+r")
	 (const_int 2)
	 (const_int 7))
	(match_operand:SI 1 "register_operand" "r")))]
  ""
  "tblidxb0\t%0,%1

(define_insn "*insv_1"
  [(set (zero_extract:SI
	 (match_operand:SI 0 "register_operand" "+r")
	 (const_int 0)
	 (match_operand:SI 1 "u5bit_cint_operand" ""))
	(match_operand:SI 2 "register_operand" "r")))]
  ""
  "mm\t%0,%0,%2,0,%1")

(define_insn "*insv_2"
  [(set (zero_extract:SI
	  (match_operand:SI 0 "register_operand" "+r")
	  (match_operand:SI 1 "u5bit_cint_operand" "")
	  (match_operand:SI 2 "u5bit_cint_operand" ""))
	(zero_extract:SI
	  (match_operand:SI 3 "register_operand" "r")
	  (match_dup 1)
	  (match_dup 2)))]
  ""
{
  operands[2] = GEN_INT (INTVAL (operands[1]) + INTVAL (operands[2]));
  return "mm\t%0,%0,%3,%1,%2";
})

You'll probably want to keep your existing "*mm" pattern, but these are
things that the combine pass is likely to generate.

> (define_insn_and_split "*addsi3_big_immediate"
>   [(set (match_operand:SI 0 "register_operand" "=r")
>         (plus:SI (match_operand:SI 1 "reg_or_0_operand" "%rO")
>                  (match_operand:SI 2 "const_int_operand" "i")))]
>   "! add_operand (operands[2], SImode)"
>   "#"
>   "&& 1"
>   [(const_int 0)]
> {
>   bool ok = tilepro_expand_addsi (operands[0], operands[1], operands[2]);
>   gcc_assert (ok);
>   DONE;
> })

Similar question to movsi_big_immediate.

> ;; Change a rotate right to a rotate left, since that's all we have.
> (define_expand "rotrsi3"
>   [(set (match_operand:SI 0 "register_operand" "")
>         (rotate:SI (match_operand:SI 1 "reg_or_0_operand" "")
>                    (match_operand:SI 2 "reg_or_u5bit_operand" "")))]
>   ""
>   "
>   if (CONST_INT_P (operands[2]))
>     {
>       operands[2] = GEN_INT ((-INTVAL (operands[2])) & 31);
>     }
>   else
>     {
>       /* No need to subtract from 32 since count taken mod 32 anyway. */
>       rtx reg = gen_reg_rtx (SImode);
>       emit_insn (gen_negsi2 (reg, operands[2]));
>       operands[2] = reg;
>     }
>   ")

optabs.c will do exactly this if the pattern is not present.  Similarly
for the DImode logicals (popcount, parity, etc).

> (define_insn "*mnz_insn"
> (define_insn "*mnz_insn_reverse"
> (define_insn "*mz_insn"
> (define_insn "*mz_insn_reverse"
> (define_insn "mvnz_insn"
> (define_insn "*mvnz_insn_reverse"

All of these ought to be compressed into a single pattern.  Otherwise reload
won't get a chance to select the proper alternative all the time.

(define_predicate "eqne_operator"
  (match_code "eq,ne"))

(define_insn "*movcc"
  [(set (match_operand:SI 0 "register_operand"		"=r, r, r, r")
	(if_then_else:SI
	  (match_operator 4 "eqne_operator"
	    [(match_operand:SI 1 "reg_or_0_operand"	"rO,rO,rO,rO")
	     (const_int 0)])
	  (match_operand:SI 2 "reg_or_0_operand"	"rO, O,rO, 0")
	  (match_operand:SI 3 "reg_or_0_operand"	" O,rO, 0,rO")))]
  ""
  "@
   m%c4 %0, %r1, %r2
   m%C4 %0, %r1, %3
   mv%c4 %0, %r1, %r2
   mv%C4 %0, %r1, %r3
  [(set_attr "type" "*,*,Y0,Y0")])

And print_operand handling %c as printing a condition (z, nz) and %C
printing its inverse.

> (define_insn "zero_extendqihi2"

Should not be needed.

> (define_insn "*lh"
> (define_insn_and_split "*extendhisi2"

These need to be combined in order for reload to do the right thing.
Suppose some HImode variable is spilled to the stack.  If you split
the patterns, reload will perform a load then split to the two shifts.
If you combine the patterns, reload will notice memory is an alternative
and perform the LH right away.

Similarly for extendqihi2.

> ;; Divide stubs.  These exist to work around a bug in expmed.c, which
> ;; will not attempt to convert a divide by constant into a multiply
> ;; unless there is a pattern for a divide of the same mode.

If this is still present in mainline, please file a bug.

> (define_insn "_return"
>   [(return)
>    (use (reg:SI 55))]
>   "reload_completed"
>   "jrp\tlr"
>   [(set_attr "type" "X1")])

Post merge, consider changing this to simple_return to enable shrink
wrapping.  This may also involve epilogue unwind fixups though.

> (define_insn "add_small_got"
>   [(set (match_operand:SI 0 "register_operand" "=r")
>         (lo_sum:SI (match_operand:SI 1 "reg_or_0_operand" "rO")
>                    (unspec:SI [(match_operand:SI 2 "symbolic_operand" "")]
>                               UNSPEC_GOT_SYM)))]

I strongly suggest that you wrap these unspecs in CONST, and handle
them as appropriate in the previous HIGH/LO_SUM patterns, and in the
print_operand cases.  This goes for the TLS patterns as well.

I'm surprised you don't support post_{inc,dec,modify} addressing modes,
via the "add" set of memory instructions.  Do they not really perform
well on the architecture, or did the gcc version you started with not
generate them well?

I also don't see support for AND addresses, as for lw_na.  And yet you
seem to be using those addressing modes in tilepro_expand_unaligned_load.
I can only assume these are failing validate_mem, and forcing the
address into a register first?

> tilepro_allocate_stack (rtx op0, rtx op1)

Invalid rtl sharing in this function.

>   /* Mark all insns we just emitted as frame-related.  */
>   for (; last_insn != NULL_RTX; last_insn = next_insn (last_insn))
>     RTX_FRAME_RELATED_P (last_insn) = 1;

You can't do just this for the epilogue.  You have to emit
REG_CFA_RESTORE notes.

I'd prefer to see all new ports use _only_ REG_CFA_* notes,
and avoid REG_FRAME_RELATED_EXPR.  I won't force this though.

> /* We generate PC relative SYMBOL_REFs as an optimization, to avoid
>    going through the GOT when the symbol is local to the compilation
>    unit.  But such a symbol requires that the common text_label that
>    we generate at the beginning of the function be in the same section
>    as the reference to the SYMBOL_REF.  This may not be true if we
>    generate hot/cold sections.  This function looks for such cases and
>    replaces such references with the longer sequence going through the GOT.

Why not use gp-relative references?  A small matter of extending the
assembler with new relocations, perhaps.

>   fprintf (file, "\tlw    r11, r10\n");
>   fprintf (file, "\taddi  r10, r10, 4\n");
>   fprintf (file, "\tlw    r10, r10\n");

I guess going back to the previous question, not

	lwadd	r11, r10, 4
	lw	r10, r10

?


r~

Re: [PING2] New port for ... TILE-Gx

[Richard Henderson]

On 11/07/2011 03:28 PM, Walter Lee wrote:
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02084.html

TileGx:

Almost all the same comments as for TilePro.

I see that you've started some macroization of the port, but havn't completed it.  E.g. sub<mode>3 vs addsi3+adddi3.

> (define_expand "addsf3"

Clever.  I do wonder if it wouldn't be better to wait until after reload to split these though.

> (define_insn "*and_0x00000000FFFFFFFF"
> (define_insn "*and_0xFFFFFFFF00000000"

These probably should be merged into the main AND pattern.  But failing that, they're only applicable to DImode and needn't be macroized.

> (define_expand "clzsi2"
>   [(set (match_dup 2)
>         (ashift:DI (match_operand:SI 1 "reg_or_0_operand" "")
>                    (const_int 32)))
>    (set (subreg:DI (match_operand:SI 0 "register_operand" "") 0)
>         (clz:DI (match_dup 2)))]
>    ""

Generic code can handle this.  Likewise ctz, popcount, parity.

> (define_insn "insn_cmpexch<four_if_si>"
> (define_insn "insn_exch<four_if_si>"
> (define_insn "insn_fetchadd<four_if_si>"
> (define_insn "insn_fetchand<four_if_si>"
> (define_insn "insn_fetchor<four_if_si>"

Use the atomic_ names and interfaces.

> #define LIBCALL_VALUE(MODE) gen_rtx_REG (MODE, 0)
> #define FUNCTION_VALUE_REGNO_P(N) ((N) < TILEGX_NUM_RETURN_REGS)
> #define FUNCTION_ARG_REGNO_P(N) ((N) < TILEGX_NUM_ARG_REGS)
> #define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
> #define GO_IF_MODE_DEPENDENT_ADDRESS(ADDR, LABEL) \

All of these are now target hooks.  There may be more.

> /* We represent all SI values as sign-extended DI values in
>    registers.  */
> #define TRULY_NOOP_TRUNCATION(OUTPREC, INPREC) \
>   ((INPREC) <= 32 || (OUTPREC) > 32)

I think you should be *very* careful before you insist on this.  Do you not have a memory mode that ignores the high bits for 32-bit pointers?  From the description of "memoryReadWord", it does seem like you've got modes that pre-process input addresses.

MIPS uses this because, techinically, the 32-bit operation insns produce undefined results when given inputs that are not sign-extended.  I see no such restriction in the TileGx manual.

At least in 64-bit pointer mode, I think you should drop this and make sure that you've got appropriate sign_extend patterns for all of the "x" insns.  Similar to how x86_64 does for the zero_extend patterns.


r~