diff mbox

[3/4] Add Visium support to gcc

Message ID 2262251.mrrELjuWpe@polaris
State New
Headers show

Commit Message

Eric Botcazou Dec. 22, 2014, 11:14 a.m. UTC
Revised version after Joseph's comments and latest libgcc changes.


gcc/ChangeLog

2014-12-22  Eric Botcazou  <ebotcazou@adacore.com>

	* config.gcc: Add Visium support.
	* configure.ac: Likewise.
	* configure: Regenerate.
	* doc/extend.texi (interrupt attribute): Add Visium.
	* doc/invoke.texi: Document Visium options.
	* doc/install.texi: Document Visium target.
	* doc/md.texi: Document Visium constraints.
	* common/config/visium: New directory.
	* config/visium: Likewise.

Comments

Jeff Law Dec. 23, 2014, 7:48 p.m. UTC | #1
On 12/22/14 04:14, Eric Botcazou wrote:
> Revised version after Joseph's comments and latest libgcc changes.
>
>
> gcc/ChangeLog
>
> 2014-12-22  Eric Botcazou  <ebotcazou@adacore.com>
>
> 	* config.gcc: Add Visium support.
> 	* configure.ac: Likewise.
> 	* configure: Regenerate.
> 	* doc/extend.texi (interrupt attribute): Add Visium.
> 	* doc/invoke.texi: Document Visium options.
> 	* doc/install.texi: Document Visium target.
> 	* doc/md.texi: Document Visium constraints.
> 	* common/config/visium: New directory.
> 	* config/visium: Likewise.
I don't see anything particularly offensive.  Actually it looks like a 
reasonably clean RISC port.

I'm a little concerned about the MODES_TIEABLE_P definition, but if it's 
working, I wouldn't mess with it.

Any thoughts on using LRA for this port?  Ideally we want to be moving 
away from reload as much as we can.

I didn't look closely, do you need blockage insns in your epilogue/prologue?

For the prologue, if you store callee saved registers using the frame 
pointer, then you need a blockage to ensure those stores don't bubble up 
before the local stack gets allocated.  And you need something analogous 
in the epilogue.  I didn't check your port carefully for this, but I'd 
advise doing so.

Presumably you're going to be the maintainer for this port?  If not you, 
then who will maintain the port (so i can get maintainership officially 
blessed by the SC).

I think this is good to go into the trunk.  The blockage issue (if it's 
an issue) can be resolved as a follow-up.

Jeff
Eric Botcazou Jan. 3, 2015, 3:16 p.m. UTC | #2
> I don't see anything particularly offensive.  Actually it looks like a
> reasonably clean RISC port.

Thanks for the review.

> I'm a little concerned about the MODES_TIEABLE_P definition, but if it's
> working, I wouldn't mess with it.

Could you elaborate?  Do you find it too restrictive?

> Any thoughts on using LRA for this port?  Ideally we want to be moving
> away from reload as much as we can.

I can only promise to start experimenting with it and report issues, if any.
The port is quite mature and the performances are closely monitored so bold 
changes need to be made with extra caution.

> I didn't look closely, do you need blockage insns in your epilogue/prologue?

No, I don't think so.

> For the prologue, if you store callee saved registers using the frame
> pointer, then you need a blockage to ensure those stores don't bubble up
> before the local stack gets allocated.  And you need something analogous
> in the epilogue.  I didn't check your port carefully for this, but I'd
> advise doing so.

The register saves in the prologue are based on the stack pointer because the 
frame pointer is established only at the very end and its value comprises the 
allocation.  The restores in the epilogue are also based on the stack pointer 
and the stack_restore and stack_pop patterns which do the deallocation have an 
explicit memory barrier.

> Presumably you're going to be the maintainer for this port?

Yes, I'm going to be the maintainer for now.

> I think this is good to go into the trunk.  The blockage issue (if it's
> an issue) can be resolved as a follow-up.

OK, thanks again.
Jeff Law Jan. 5, 2015, 7:38 p.m. UTC | #3
On 01/03/15 08:16, Eric Botcazou wrote:
>
>> I'm a little concerned about the MODES_TIEABLE_P definition, but if it's
>> working, I wouldn't mess with it.
>
> Could you elaborate?  Do you find it too restrictive?
I'm a little concerned it's too loose.  Basically it says that if both 
modes are integer modes, then they're tieable.  However, 
HARD_REGNO_MODE_OK may return different values for MODE1 and MODE2, even 
if both are integer modes.

My recollection is if MODES_TIEABLE_P returns true for mode1 and mode2, 
then HARD_REGNO_MODE_OK must return the same value when passed mode1 and 
mode2 regardless of the hard register and it's not obvious if 
HARD_REGNO_MODE_OK fits that criteria for this port.

Looking at the current docs, the language has been watered down from my 
recollection.  So.....

If it's working, then I'd leave it as-is.


>
>> Any thoughts on using LRA for this port?  Ideally we want to be moving
>> away from reload as much as we can.
>
> I can only promise to start experimenting with it and report issues, if any.
> The port is quite mature and the performances are closely monitored so bold
> changes need to be made with extra caution.
Understood.

FWIW, I suspect this is the last port I'll approve that doesn't use LRA 
instead of reload.


>
> Yes, I'm going to be the maintainer for now.
Given you're already maintaining other parts of GCC, I really just 
consider appointing you as the maintainer for the port a formality. 
I'll start that process, but go ahead and list yourself as the 
maintainer in the MAINTAINERS file.

jeff
Eric Botcazou Jan. 5, 2015, 9:01 p.m. UTC | #4
> I'm a little concerned it's too loose.  Basically it says that if both
> modes are integer modes, then they're tieable.  However,
> HARD_REGNO_MODE_OK may return different values for MODE1 and MODE2, even
> if both are integer modes.
> 
> My recollection is if MODES_TIEABLE_P returns true for mode1 and mode2,
> then HARD_REGNO_MODE_OK must return the same value when passed mode1 and
> mode2 regardless of the hard register and it's not obvious if
> HARD_REGNO_MODE_OK fits that criteria for this port.

I see, thanks for explaining.  I didn't write these macros and I agree that 
HARD_REGNO_MODE_OK is a little convoluted, but MODES_TIEABLE_P is correct as 
far as the arch is concerned so I'd rather tweak the former if need be.

> Given you're already maintaining other parts of GCC, I really just
> consider appointing you as the maintainer for the port a formality.
> I'll start that process, but go ahead and list yourself as the
> maintainer in the MAINTAINERS file.

Will do.
diff mbox

Patch

Index: config.gcc
===================================================================
--- config.gcc	(revision 218987)
+++ config.gcc	(working copy)
@@ -2888,6 +2888,10 @@  vax-*-openbsd*)
 	extra_options="${extra_options} openbsd.opt"
 	use_collect2=yes
 	;;
+visium-*-elf*)
+	tm_file="dbxelf.h elfos.h ${tm_file} visium/elf.h newlib-stdint.h"
+	tmake_file="visium/t-visium visium/t-crtstuff"
+	;;
 xstormy16-*-elf)
 	# For historical reasons, the target files omit the 'x'.
 	tm_file="dbxelf.h elfos.h newlib-stdint.h stormy16/stormy16.h"
Index: configure.ac
===================================================================
--- configure.ac	(revision 218987)
+++ configure.ac	(working copy)
@@ -4442,7 +4442,7 @@  esac
 case "$cpu_type" in
   aarch64 | alpha | arm | avr | bfin | cris | i386 | m32c | m68k | microblaze \
   | mips | nios2 | pa | rs6000 | score | sparc | spu | tilegx | tilepro \
-  | xstormy16 | xtensa)
+  | visium | xstormy16 | xtensa)
     insn="nop"
     ;;
   ia64 | s390)
Index: doc/extend.texi
===================================================================
--- doc/extend.texi	(revision 218987)
+++ doc/extend.texi	(working copy)
@@ -2935,12 +2935,11 @@  least version 2.20.1), and GNU C library
 @item interrupt
 @cindex interrupt handler functions
 Use this attribute on the ARC, ARM, AVR, CR16, Epiphany, M32C, M32R/D,
-m68k, MeP, MIPS, MSP430, RL78, RX and Xstormy16 ports to indicate that
-the specified function is an
-interrupt handler.  The compiler generates function entry and exit
-sequences suitable for use in an interrupt handler when this attribute
-is present.  With Epiphany targets it may also generate a special section with
-code to initialize the interrupt vector table.
+m68k, MeP, MIPS, MSP430, RL78, RX, Visium and Xstormy16 ports to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.  With Epiphany targets it may also generate
+a special section with code to initialize the interrupt vector table.
 
 Note, interrupt handlers for the Blackfin, H8/300, H8/300H, H8S, MicroBlaze,
 and SH processors can be specified via the @code{interrupt_handler} attribute.
Index: doc/invoke.texi
===================================================================
--- doc/invoke.texi	(revision 218987)
+++ doc/invoke.texi	(working copy)
@@ -1064,6 +1064,10 @@  See RS/6000 and PowerPC Options.
 @emph{VAX Options}
 @gccoptlist{-mg  -mgnu  -munix}
 
+@emph{Visium Options}
+@gccoptlist{-mdebug -msim -mfpu -mno-fpu -mhard-float -msoft-float @gol
+-mcpu=@var{cpu-type} -mtune=@var{cpu-type} -msv-mode -muser-mode}
+
 @emph{VMS Options}
 @gccoptlist{-mvms-return-codes -mdebug-main=@var{prefix} -mmalloc64 @gol
 -mpointer-size=@var{size}}
@@ -11892,6 +11896,7 @@  platform.
 * TILEPro Options::
 * V850 Options::
 * VAX Options::
+* Visium Options::
 * VMS Options::
 * VxWorks Options::
 * x86-64 Options::
@@ -22532,6 +22537,77 @@  GNU assembler is being used.
 Output code for G-format floating-point numbers instead of D-format.
 @end table
 
+@node Visium Options
+@subsection Visium Options
+@cindex Visium options
+
+@table @gcctabopt
+
+@item -mdebug
+@opindex mdebug
+A program which performs file I/O and is destined to run on an MCM target
+should be linked with this option.  It causes the libraries libc.a and
+libdebug.a to be linked.  The program should be run on the target under
+the control of the GDB remote debugging stub.
+
+@item -msim
+@opindex msim
+A program which performs file I/O and is destined to run on the simulator
+should be linked with option.  This causes libraries libc.a and libsim.a to
+be linked.
+
+@item -mfpu
+@itemx -mhard-float
+@opindex mfpu
+@opindex mhard-float
+Generate code containing floating-point instructions.  This is the
+default.
+
+@item -mno-fpu
+@itemx -msoft-float
+@opindex mno-fpu
+@opindex msoft-float
+Generate code containing library calls for floating-point.
+
+@option{-msoft-float} changes the calling convention in the output file;
+therefore, it is only useful if you compile @emph{all} of a program with
+this option.  In particular, you need to compile @file{libgcc.a}, the
+library that comes with GCC, with @option{-msoft-float} in order for
+this to work.
+
+@item -mcpu=@var{cpu_type}
+@opindex mcpu
+Set the instruction set, register set, and instruction scheduling parameters
+for machine type @var{cpu_type}.  Supported values for @var{cpu_type} are
+@samp{mcm}, @samp{gr5} and @samp{gr6}.
+
+@samp{mcm} is a synonym of @samp{gr5} present for backward compatibility.
+
+By default (unless configured otherwise), GCC generates code for the GR5
+variant of the Visium architecture.  
+
+With @option{-mcpu=gr6}, GCC generates code for the GR6 variant of the Visium
+architecture.  The only difference from GR5 code is that the compiler will
+generate block move instructions.
+
+@item -mtune=@var{cpu_type}
+@opindex mtune
+Set the instruction scheduling parameters for machine type @var{cpu_type},
+but do not set the instruction set or register set that the option
+@option{-mcpu=@var{cpu_type}} would.
+
+@item -msv-mode
+@opindex msv-mode
+Generate code for the supervisor mode, where there are no restrictions on
+the access to general registers.  This is the default.
+
+@item -muser-mode
+@opindex muser-mode
+Generate code for the user mode, where the access to some general registers
+is forbidden: on the GR5, registers r24 to r31 cannot be accessed in this
+mode; on the GR6, only registers r29 to r31 are affected.
+@end table
+
 @node VMS Options
 @subsection VMS Options
 
Index: doc/md.texi
===================================================================
--- doc/md.texi	(revision 218987)
+++ doc/md.texi	(working copy)
@@ -3972,6 +3972,56 @@  A 2-element vector constant with identic
 
 @end table
 
+@item Visium---@file{config/visium/constraints.md}
+@table @code
+@item b
+EAM register @code{mdb}
+
+@item c
+EAM register @code{mdc}
+
+@item f
+Floating point register
+
+@ifset INTERNALS
+@item k
+Register for sibcall optimization
+@end ifset
+
+@item l
+General register, but not @code{r29}, @code{r30} and @code{r31}
+
+@item t
+Register @code{r1}
+
+@item u
+Register @code{r2}
+
+@item v
+Register @code{r3}
+
+@item G
+Floating-point constant 0.0
+
+@item J
+Integer constant in the range 0 .. 65535 (16-bit immediate)
+
+@item K
+Integer constant in the range 1 .. 31 (5-bit immediate)
+
+@item L
+Integer constant in the range @minus{}65535 .. @minus{}1 (16-bit negative immediate)
+
+@item M
+Integer constant @minus{}1
+
+@item O
+Integer constant 0
+
+@item P
+Integer constant 32
+@end table
+
 @item Xtensa---@file{config/xtensa/constraints.md}
 @table @code
 @item a
Index: doc/install.texi
===================================================================
--- doc/install.texi	(revision 218987)
+++ doc/install.texi	(working copy)
@@ -3349,6 +3349,8 @@  information have to.
 @item
 @uref{#tilepro-x-linux,,tilepro-*-linux*}
 @item
+@uref{#visium-x-elf, visium-*-elf}
+@item
 @uref{#x-x-vxworks,,*-*-vxworks*}
 @item
 @uref{#x86-64-x-x,,x86_64-*-*, amd64-*-*}
@@ -4649,6 +4651,14 @@  binutils-2.22 or newer.
 
 @html
 <hr />
+@end html
+@anchor{visium-x-elf}
+@heading visium-*-elf
+CDS VISIUMcore processor.
+This configuration is intended for embedded systems.
+
+@html
+<hr />
 @end html
 @anchor{x-x-vxworks}
 @heading *-*-vxworks*
Index: common/config/visium/visium-common.c
===================================================================
--- common/config/visium/visium-common.c	(revision 0)
+++ common/config/visium/visium-common.c	(revision 0)
@@ -0,0 +1,38 @@ 
+/* Common hooks for Visium.
+   Copyright (C) 2002-2014 Free Software Foundation, Inc.
+   Contributed by C.Nettleton,J.P.Parkes and P.Garbett.
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC 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.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+<http://www.gnu.org/licenses/>.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "common/common-target.h"
+#include "common/common-target-def.h"
+
+/* Set default optimization options.  */
+static const struct default_options visium_option_optimization_table[] =
+  {
+    { OPT_LEVELS_1_PLUS, OPT_fomit_frame_pointer, NULL, 1 },
+    { OPT_LEVELS_NONE, 0, NULL, 0 }
+  };
+
+#undef TARGET_OPTION_OPTIMIZATION_TABLE
+#define TARGET_OPTION_OPTIMIZATION_TABLE visium_option_optimization_table
+
+struct gcc_targetm_common targetm_common = TARGETM_COMMON_INITIALIZER;