This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH, MIPS] I6400 scheduling
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Robert Suchanek <Robert dot Suchanek at imgtec dot com>, "Catherine_Moore at mentor dot com" <Catherine_Moore at mentor dot com>, Prachi Godbole <Prachi dot Godbole at imgtec dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 21 Jul 2015 10:42:36 +0000
- Subject: RE: [PATCH, MIPS] I6400 scheduling
- Authentication-results: sourceware.org; auth=none
- References: <B5E67142681B53468FAF6B7C31356562441ABA1F at hhmail02 dot hh dot imgtec dot org>
Robert Suchanek <Robert.Suchanek@imgtec.com> writes:
> 2015-07-16 Prachi Godbole <prachi.godbole@imgtec.com>
>
> gcc/
> * config/mips/i6400.md: New file.
> * config/mips/mips-cpus.def (mips32r6): Change to PROCESSOR_I6400.
> (mips64r6): Likewise.
> (i6400): Define.
> * config/mips/mips-tables.opt: Regenerate.
> * config/mips/mips.c (mips_rtx_cost_data): Add I6400 processor.
> (mips_issue_rate): Add support for i6400.
> (mips_multipass_dfa_lookahead): Likewise.
> * config/mips/mips.h (TUNE_I6400): Define.
> * config/mips/mips.md: Include i6400.md.
> (processor): Add i6400.
> * doc/invoke.texi (-march=@var{arch}): Add i6400.
Apologies, I thought Catherine had done this one but not the M5100. Just
a couple of things...
> ---
> gcc/config/mips/i6400.md | 142
> ++++++++++++++++++++++++++++++++++++++++
> gcc/config/mips/mips-cpus.def | 7 +-
> gcc/config/mips/mips-tables.opt | 3 +
> gcc/config/mips/mips.c | 16 ++++-
> gcc/config/mips/mips.h | 3 +-
> gcc/config/mips/mips.md | 2 +
> gcc/doc/invoke.texi | 1 +
> 7 files changed, 170 insertions(+), 4 deletions(-) create mode 100644
> gcc/config/mips/i6400.md
>
> diff --git a/gcc/config/mips/i6400.md b/gcc/config/mips/i6400.md new
> file mode 100644 index 0000000..101a20c
> --- /dev/null
> +++ b/gcc/config/mips/i6400.md
> @@ -0,0 +1,142 @@
> +;; DFA-based pipeline description for I6400.
> +;;
> +;; Copyright (C) 2007-2015 Free Software Foundation, Inc.
This should just be 2015.
> diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-
> cpus.def index fb4bae0..90836a3 100644
> --- a/gcc/config/mips/mips-cpus.def
> +++ b/gcc/config/mips/mips-cpus.def
> @@ -50,13 +50,13 @@ MIPS_CPU ("mips32r2", PROCESSOR_74KF2_1, 33,
> PTF_AVOID_BRANCHLIKELY)
> as mips32r2. */
> MIPS_CPU ("mips32r3", PROCESSOR_M4K, 34, PTF_AVOID_BRANCHLIKELY)
> MIPS_CPU ("mips32r5", PROCESSOR_P5600, 36, PTF_AVOID_BRANCHLIKELY) -
> MIPS_CPU ("mips32r6", PROCESSOR_W32, 37, PTF_AVOID_BRANCHLIKELY)
> +MIPS_CPU ("mips32r6", PROCESSOR_I6400, 37, PTF_AVOID_BRANCHLIKELY)
> MIPS_CPU ("mips64", PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY)
> /* ??? For now just tune the generic MIPS64r2 and above for 5KC as
> well. */
> MIPS_CPU ("mips64r2", PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY)
> MIPS_CPU ("mips64r3", PROCESSOR_5KC, 66, PTF_AVOID_BRANCHLIKELY)
> MIPS_CPU ("mips64r5", PROCESSOR_5KC, 68, PTF_AVOID_BRANCHLIKELY) -
> MIPS_CPU ("mips64r6", PROCESSOR_W64, 69, PTF_AVOID_BRANCHLIKELY)
> +MIPS_CPU ("mips64r6", PROCESSOR_I6400, 69, PTF_AVOID_BRANCHLIKELY)
>
> /* MIPS I processors. */
> MIPS_CPU ("r3000", PROCESSOR_R3000, 1, 0) @@ -166,3 +166,6 @@ MIPS_CPU
> ("octeon+", PROCESSOR_OCTEON, 65, PTF_AVOID_BRANCHLIKELY) MIPS_CPU
> ("octeon2", PROCESSOR_OCTEON2, 65, PTF_AVOID_BRANCHLIKELY) MIPS_CPU
> ("octeon3", PROCESSOR_OCTEON3, 65, PTF_AVOID_BRANCHLIKELY) MIPS_CPU
> ("xlp", PROCESSOR_XLP, 65, PTF_AVOID_BRANCHLIKELY)
> +
> +/* MIPS64 Release 6 processors. */
> +MIPS_CPU ("i6400", PROCESSOR_I6400, 69, PTF_AVOID_BRANCHLIKELY)
I don't think this really matters but the PTF_AVOID_BRANCHLIKELY should
not be necessary for R6 cores as there are no branch likely instructions.
Changing this may also require an update to the option handling code
in mips.c I don't know if it will try to enable branch likely if you
remove this.
OK with those changes.
Does the I6400 support load/store bonding? I seem to think it does but
could be wrong. If it does then dealing with it in a follow up patch is
OK with me.
Thanks,
Matthew