Re: [PATCH 3/4] Add Visium support to gcc
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
Re: [PATCH 3/4] Add Visium support to gcc
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. -- Eric Botcazou
Re: [PATCH 3/4] Add Visium support to gcc
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. -- Eric Botcazou
Re: [PATCH 3/4] Add Visium support to gcc
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 ebotca...@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
Re: [PATCH 3/4] Add Visium support to gcc
Revised version after Joseph's comments and latest libgcc changes.
gcc/ChangeLog
2014-12-22 Eric Botcazou ebotca...@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.
--
Eric Botcazou
gcc_visium-2.tar.gz
Description: application/compressed-tar
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,
Re: [PATCH 3/4] Add Visium support to gcc
First, bootstrap a native compiler from current trunk. Then, use that native compiler to build the cross compiler configured with --enable-werror-always. (--enable-werror-always is only expected to work when GCC is being built with the same version of GCC, as the compiler may not be -Werror-clean when built with other versions.) Do this for both 32-bit and 64-bit hosts. Done, no changes required. -- Eric Botcazou
Re: [PATCH 3/4] Add Visium support to gcc
On Mon, 15 Dec 2014, Eric Botcazou wrote: (and you should verify that the port builds cleanly with --enable-werror -always, for both 32-bit and 64-bit hosts, when building using current trunk GCC). Do you mean a bootstrap of the cross-compiler with --enable-werror-always on a 32-bit and a 64-bit host? OK, I'll do that. First, bootstrap a native compiler from current trunk. Then, use that native compiler to build the cross compiler configured with --enable-werror-always. (--enable-werror-always is only expected to work when GCC is being built with the same version of GCC, as the compiler may not be -Werror-clean when built with other versions.) Do this for both 32-bit and 64-bit hosts. For a cross-compiler, doing this provides equivalent -Werror coverage to what simple bootstrap does for a native compiler. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH 3/4] Add Visium support to gcc
Use of `%s' in diagnostics is long obsoleted by %qs (in this case, using
%qE with the identifier directly, rather than using IDENTIFIER_POINTER, is
preferred).
Only occurrence fixed by mimicing the i386 port.
INTVAL / UINTVAL return HOST_WIDE_INT / unsigned HOST_WIDE_INT, not long /
unsigned long. You have lots of uses of fprintf that presume they return
long / unsigned long.
Changed into HOST_WIDE_INT_PRINT_DEC/HOST_WIDE_INT_PRINT_UNSIGNED.
As you have the interrupt attribute, you need to add this port to the list
in extend.texi of ports with this attribute. (Generally, check the
checklist of pieces in sourcebuild.texi to update for a new port.)
Done. But there is a bit of a contradiction in sourcebuild.texi:
* Entries in `gcc/doc/install.texi' for all target triplets
supported with this target architecture, giving details of any
special notes about installation for this target, or saying that
there are no special notes if there are none.
But gcc/doc/install.texi has:
Note that this list of install notes is @emph{not} a list of supported
hosts or targets. Not all supported hosts and targets are listed
here, only the ones that require host-specific or target-specific
information have to.
I have nevertheless added visium-*-elf to gcc/doc/install.texi.
I'll note that libbacktrace, libcc1, libcilkrts, liboffloadmic, libsanitizer
and libvtv are not documented in there.
At least one target for this port should be added to contrib/config-list.mk
This is documented in sourcebuild.texi, I'll take the 5 steps covered by If
the back end is added to the official GCC source repository, the following are
also necessary: when the premise is fulfilled.
(and you should verify that the port builds cleanly with --enable-werror
-always, for both 32-bit and 64-bit hosts, when building using current trunk
GCC).
Do you mean a bootstrap of the cross-compiler with --enable-werror-always on a
32-bit and a 64-bit host? OK, I'll do that.
Thanks for the review.
--
Eric Botcazou
[PATCH 3/4] Add Visium support to gcc
gcc/ChangeLog
2014-12-11 Eric Botcazou ebotca...@adacore.com
* config.gcc: Add Visium support.
* configure.ac: Likewise.
* configure: Regenerate.
* doc/invoke.texi: Document Visium options.
* doc/md.texi: Document Visium constraints.
* common/config/visium: New directory.
* config/visium: Likewise.
--
Eric BotcazouIndex: config.gcc
===
--- config.gcc (revision 218617)
+++ config.gcc (working copy)
@@ -2853,6 +2853,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 218617)
+++ 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/invoke.texi
===
--- doc/invoke.texi (revision 218617)
+++ doc/invoke.texi (working copy)
@@ -1062,6 +1062,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}}
@@ -11845,6 +11849,7 @@ platform.
* TILEPro Options::
* V850 Options::
* VAX Options::
+* Visium Options::
* VMS Options::
* VxWorks Options::
* x86-64 Options::
@@ -22456,6 +22461,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 218642)
+++ doc/md.texi (working copy)
@@ -3974,6 +3974,56 @@ A 2-element vector constant with identic
@end table
+@item
Re: [PATCH 3/4] Add Visium support to gcc
Use of `%s' in diagnostics is long obsoleted by %qs (in this case, using %qE with the identifier directly, rather than using IDENTIFIER_POINTER, is preferred). INTVAL / UINTVAL return HOST_WIDE_INT / unsigned HOST_WIDE_INT, not long / unsigned long. You have lots of uses of fprintf that presume they return long / unsigned long. As you have the interrupt attribute, you need to add this port to the list in extend.texi of ports with this attribute. (Generally, check the checklist of pieces in sourcebuild.texi to update for a new port.) At least one target for this port should be added to contrib/config-list.mk (and you should verify that the port builds cleanly with --enable-werror-always, for both 32-bit and 64-bit hosts, when building using current trunk GCC). -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH 3/4] Add Visium support to gcc
On Fri, 12 Dec 2014, Joseph Myers wrote: At least one target for this port should be added to contrib/config-list.mk (and you should verify that the port builds cleanly with --enable-werror-always, for both 32-bit and 64-bit hosts, when building using current trunk GCC). While doing that, beware that gcc has bugs causing some ports (I forgot which ones) to get at least one spurious warning apparently not attributable to the quality of the port. PR(s) duly entered, but I can't quote the numbers (finding PRs is not practical for me after the https change, but IIRC Joern was the author). brgds, H-P PS. of course no excuse to not get the low-hanging fruit.
