Re: [patch, mips] Fix optimization bug involving nor instruction

[Steve Ellcey]

On Tue, 2013-10-22 at 19:12 +0100, Richard Sandiford wrote:

  Richard
 
  OK, but I am curious why you put parenthesis around the right hand side
  of the total expression.  I.e.  *total = ();
 
 That's the emacs formatting rule:

OK, I have checked in the patch with the parenthesis (and your other
changes).

Steve

Re: [PATCH][i386]Fix PR 57756

[Steve Ellcey]

On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
 On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@gmail.com wrote:
 
  How is Google going to change its patch commit policies to ensure that
  this does not happen again?
 
 There is nothing to change.  Google follows
 http://gcc.gnu.org/contribute.html, like everyone else. Sri just fixed
 the oversight and if there is any other fallout from his patch, he
 will address it.
 
 I don't see anything out of the ordinary here.
 
 
 Diego.

FYI: I just want to make sure everyone is aware that there are still
broken targets.  rs6000 may be fixed but mips still doesn't work and
I presume other platforms like sparc are also still broken.

/local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c: In
function 'void cpp_atomic_builtins(cpp_reader*)':
/local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c:594:7: 
error: 'target_flags_explicit' was not declared in this scope
/local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c:606:7: 
error: 'target_flags_explicit' was not declared in this scope
/local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c:618:7: 
error: 'target_flags_explicit' was not declared in this scope
/local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c:630:7: 
error: 'target_flags_explicit' was not declared in this scope
make[1]: *** [c-family/c-cppbuiltin.o] Error 1

Sriraman, are you looking at how to fix this globally or are the target
maintainers expected to fix this?  Currently I am using this one line
patch to get things building, but I presume this is not what we want
long term.


% git diff opth-gen.awk
diff --git a/gcc/opth-gen.awk b/gcc/opth-gen.awk
index 01c5ab6..46bd570 100644
--- a/gcc/opth-gen.awk
+++ b/gcc/opth-gen.awk
@@ -114,6 +114,7 @@ print };
 print extern struct gcc_options global_options;
 print extern const struct gcc_options global_options_init;
 print extern struct gcc_options global_options_set;
+print #define target_flags_explicit global_options_set.x_target_flag
s
 print #endif
 print #endif
 print 


Steve Ellcey
sell...@mips.com

Re: [PATCH][i386]Fix PR 57756

[Steve Ellcey]

On Thu, 2013-10-17 at 11:06 -0700, Xinliang David Li wrote:
 JBG, Steve, Can you help testing Sri's latest patch on your targets?
 This will help speed up the process.
 
 thanks,
 
 David

I have already tested the one line patch to opth-gen.awk.  It fixes the
MIPS build and a testsuite run looked OK too.

Steve Ellcey
sell...@mips.com

Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib

[Steve Ellcey]

On Tue, 2013-10-01 at 12:40 +0100, Marcus Shawcroft wrote:
 On 30/09/13 13:40, Marcus Shawcroft wrote:
 
  Well, I thought this patch would work for me, but it does not.  It looks
  like gcc_no_link is set to 'no' on my target because, technically, I can
  link even if I don't use a linker script.  I just can't find any
  functions.
 
 
  In which case gating on gcc_no_link could be replaced with a test that
  looks to see if we can link with the library.  Perhaps looking for
  exit() or some such that might reasonably be expected to be present.
 
  For example:
 
  AC_CHECK_FUNC(exit)
  if test x${with_newlib} = xyes -a x${ac_cv_func_exit} = xno; then
 
  /Marcus

This patch works on my mips-mti-elf target.

Steve Ellcey
sell...@mips.com

Re: [PATCH] Fix libgfortran cross compile configury w.r.t newlib

[Steve Ellcey]

On Thu, 2013-09-26 at 14:47 +0100, Marcus Shawcroft wrote:

 I'm in two minds about whether further sticky tape of this form is the 
 right approach or whether the original patch should be reverted until a 
 proper fix that does not regress the tree can be found.
 
 Thoughts?
 
 2013-09-26  Marcus Shawcroft  marcus.shawcr...@arm.com
 
  * configure.ac (AC_CHECK_FUNCS_ONCE): Make if statement
  dependent on gcc_no_link.
 
 Cheers
 /Marcus

Well, I thought this patch would work for me, but it does not.  It looks
like gcc_no_link is set to 'no' on my target because, technically, I can
link even if I don't use a linker script.  I just can't find any
functions.


% cat x.c
int main (void) { return 0; }
% mips-mti-elf-gcc x.c -o x
/local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.9.0/../../../../mips-mti-elf/bin/ld:
 warning: cannot find entry symbol __start; defaulting to 00400098
% echo $?
0


% cat y.c
int main (void) { exit (0); }
% install-mips-mti-elf/bin/mips-mti-elf-gcc y.c -o y
/local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.9.0/../../../../mips-mti-elf/bin/ld:
 warning: cannot find entry symbol __start; defaulting to 00400098
/tmp/ccdG78PN.o: In function `main':
y.c:(.text+0x14): undefined reference to `exit'
collect2: error: ld returned 1 exit status
ubuntu-sellcey % echo $?
1


Steve Ellcey
sell...@mips.com

Re: [PATCH] Fix libgfortran cross compile configury w.r.t newlib

[Steve Ellcey]

On Thu, 2013-09-26 at 14:47 +0100, Marcus Shawcroft wrote:

 I'm in two minds about whether further sticky tape of this form is the 
 right approach or whether the original patch should be reverted until a 
 proper fix that does not regress the tree can be found.
 
 Thoughts?
 
 2013-09-26  Marcus Shawcroft  marcus.shawcr...@arm.com
 
  * configure.ac (AC_CHECK_FUNCS_ONCE): Make if statement
  dependent on gcc_no_link.
 
 Cheers
 /Marcus

I think this patch is a good fix.  I (obviously) don't favor reverting
the previous patch because that would re-break the Fortran build on MIPS
bare-metal cross compilers (or any compiler where a linker script is
needed).  Any 'proper' fix should address libstdc++, libjava, and other
libraries as well as libgfortran and I don't know what a cleaner fix
would be.  In fact I would say the other libraries should consider using
this fix.  The only reason they don't run into this problem too is that
they don't depend on any long double functions or any other functions
that are optionally built by newlib.

I will test this patch on my targets and make sure it works for me, but
I don't see why it would not.

Steve Ellcey
sell...@mips.com

Re: RFA: Store the REG_BR_PROB probability directly as an int

[Steve Ellcey]

On Tue, 2013-09-24 at 21:07 +0200, Andreas Schwab wrote:
 Richard Sandiford rdsandif...@googlemail.com writes:
 
  Sorry for the breakage.  I think we need to handle INT_LIST in the same way
  as INSN_LIST though, and eliminate in XEXP (x, 1).
 
  How about the attached?  Testing in progress...
 
 Works for me as well.
 
 Andreas.

This patch worked for me as well on MIPS.  I did a complete build and
test overnight.

Steve Ellcey
sell...@mips.com

Re: [patch, libgfortran, configure] Cross-compile support for libgfortran

[Steve Ellcey]

On Mon, 2013-09-23 at 16:26 +0100, Marcus Shawcroft wrote:
 On 4 June 2013 20:49, Steve Ellcey sell...@mips.com wrote:
  This patch allows me to build libgfortran for a cross-compiling toolchain
  using newlib.  Currently the checks done by AC_CHECK_FUNCS_ONCE fail with
  my toolchain because the compile/link fails due to the configure script not
  using the needed linker script in the link command.  The check for 
  with_newlib
  is how libjava deals with the problem and it fixes my build problems.
 
  My only concern is defining HAVE_STRTOLD, strtold exists in my newlib but
  I am not sure if that is true for all newlib builds.  I didn't see any
  flags that I could easily use to check for long double support in the
  libgfortran configure.ac, but it seems to assume that the type exists.
 
  OK to checkin?
 
 This patch breaks systems where long double is wider than double.  The
 newlib implementation provides strtold for systems where double is as
 wide as long double but not on systems where long double is wider.
 
 I don;t see any issues with AC_CHECK_FUNC_ONCE when cross configuring
 aarch64 toolchains but I would have thought that fixing the link test
 issue you encountered would be preferable to hard coding assumptions
 in the configure script?
 
 Cheers
 /Marcus

AC_CHECK_FUNC_ONCE may work for aarch64 but I don't think there is
anyway to make it work generally for all platforms.  In the libjava
configure.ac file is the comments:

[dnl Botheration.  Now we've got to detect the exception model.
dnl Link tests against libgcc.a are problematic since -- at least
dnl as of this writing -- we've not been given proper -L bits for
dnl single-tree newlib and libgloss.

and:

   # We are being configured with a cross compiler.  AC_REPLACE_FUNCS
   # may not work correctly, because the compiler may not be able to
   # link executables.


The libstdc++ configure has comments to the same effect:

  # This lets us hard-code the functionality we know we'll have in the cross
  # target environment.  Let is a sugar-coated word placed on an especially
  # dull and tedious hack, actually.
  #
  # Here's why GLIBCXX_CHECK_MATH_SUPPORT, and other autoconf macros
  # that involve linking, can't be used:
  #cannot open sim-crt0.o
  #cannot open crt0.o
  # etc.  All this is because there currently exists no unified, consistent
  # way for top level CC information to be passed down to target directories:
  # newlib includes, newlib linking info, libgloss versus newlib crt0.o, etc.
  # When all of that is done, all of this hokey, excessive AC_DEFINE junk for
  # crosses can be removed.

The libstdc++ configure file has something that looks like it might be
intended to address the problem of long double support
(long_double_math_on_this_cpu) but I don't see where that variable is
ever set in any configure file even though it is used in the libstdc++
configure file.

Steve Ellcey
sell...@mips.com

Re: [PATCH] Fix PR57451 (Incorrect debug ranges emitted for -freorder-blocks-and-partition -g)

[Steve Ellcey]

On Fri, 2013-08-23 at 07:38 -0700, Teresa Johnson wrote:

  It should be committed soon, by Kaz or myself once testing finishes.
  Please let me know if that doesn't fix your failures.
 
 Fix committed as r201941. Let me know if you still have issues.
 
 Teresa

This patch fixes the problem for me.  Thanks Teresa, Thanks Kaz.

Steve Ellcey

Re: [PATCH] Fix PR57451 (Incorrect debug ranges emitted for -freorder-blocks-and-partition -g)

[Steve Ellcey]

On Mon, 2013-08-19 at 22:21 -0700, Teresa Johnson wrote:

 2013-08-19  Teresa Johnson  tejohn...@google.com
 
 PR rtl-optimizations/57451
 * final.c (reemit_insn_block_notes): Prevent lexical blocks
 from crossing split section boundaries.
 
 * testsuite/g++.dg/tree-prof/pr57451.C: New test.

Teresa,

This patch is causing a problem in my mips compiler.  I am creating a
cross-toolchain running on x86 targeting mips-mti-linux-gnu and if I
compile glibc using a GCC that has this patch all of the programs I
compile go into an infinite loop when run under the qemu simulator.  I
think it is the dynamic linker that is getting miscompiled, but I
haven't tracked down the exact nature of the miscompilation yet.  Has
anyone else reported any problems with it?  I am adding Richard
Sandiford to the email list since he is a mips expert and also might
have some insight to using next_active_insn vs. next_real_insn vs.
next_insn, though it doesn't look like you have changed what is used
here.

Steve Ellcey
sell...@mips.com

[patch, libtool] Top-level libtool.m4 patch for autoconf 2.68

[Steve Ellcey]

Some of the binutils directories (libgloss and newlib) have moved from
autoconf 2.64 to 2.68.  While running autoconf 2.68 on these directories
I get some warnings coming from libtool.m4 which is at the top level
of the GCC and binutils trees.  Fixes for these warnings are already in
the upstream libtool sources and the changes work fine with autoconf 2.64
as well as autoconf 2.68 so I would like to put these fixes into the
libtool.m4 at the GCC and binutils top-levels.

I ran autoconf in various GCC and binutils directories to verify that no
signficant changes ocurred in any directories, is this patch OK to check
in to the GCC tree?  I will send seperate email to the binutils mailing
list though perhaps permission to check it in to the GCC tree is sufficient
to put it in binutils as well?

Steve Ellcey
sell...@mips.com


2013-08-20  Steve Ellcey  sell...@mips.com

* libtool.m4 (_LT_SYS_MODULE_PATH_AIX): Put AC_LANG_PROGRAM
call in brackets.
(irix*|nonstopux*): use AC_LANG_SOURCE in AC_LINK_IFELSE call.


diff --git a/libtool.m4 b/libtool.m4
index 8a14e2b..7119b35 100644
--- a/libtool.m4
+++ b/libtool.m4
@@ -1079,7 +1079,7 @@ m4_defun([_LT_DARWIN_LINKER_FEATURES],
 # to the aix ld manual.
 m4_defun([_LT_SYS_MODULE_PATH_AIX],
 [m4_require([_LT_DECL_SED])dnl
-AC_LINK_IFELSE(AC_LANG_PROGRAM,[
+AC_LINK_IFELSE([AC_LANG_PROGRAM],[
 lt_aix_libpath_sed='
 /Import File Strings/,/^$/ {
/^0/ {
@@ -4926,7 +4926,16 @@ _LT_EOF
# implicitly export all symbols.
 save_LDFLAGS=$LDFLAGS
 LDFLAGS=$LDFLAGS -shared ${wl}-exported_symbol ${wl}foo 
${wl}-update_registry ${wl}/dev/null
-AC_LINK_IFELSE(int foo(void) {},
+   AC_LINK_IFELSE(
+ [AC_LANG_SOURCE(
+[AC_LANG_CASE([C], [[int foo (void) { return 0; }]],
+  [C++], [[int foo (void) { return 0; }]],
+  [Fortran 77], [[
+  subroutine foo
+  end]],
+  [Fortran], [[
+  subroutine foo
+  end]])])],
   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags ${wl}-soname ${wl}$soname `test -n $verstring  
func_echo_all ${wl}-set_version ${wl}$verstring` ${wl}-update_registry 
${wl}${output_objdir}/so_locations ${wl}-exports_file ${wl}$export_symbols -o 
$lib'
 )
 LDFLAGS=$save_LDFLAGS

Re: MIPS tests (nan-legacy.c and nans-legacy.c) failing

[Steve Ellcey]

On Tue, 2013-08-13 at 14:28 +0100, Maciej W. Rozycki wrote:

  This has passed mips-linux-gnu regression testing on a 32-bit host, but I 
 can't regression-test a 64-bit host easily -- Steve, can you please verify 
 that this change indeed works for you?  Richard, OK to apply assuming that 
 it does?

Maciej, the patch does work for me.

Steve Ellcey
sell...@mips.com

[patch, mips] Fix for loongson prefetching and -mabi=32

[Steve Ellcey]

Someone using buildroot reported a problem to me that I tracked down to
compiling a routine containing __builtin_prefetch with '-march=loongson
-mabi=32'.  When doing this the prefetch instruction on loongson generates
'ld' instead of 'lw' and then tries to put it into a delay slot.  This
causes the assembler to generate a warning both because 'ld' in 32 bit
mode is a macro and GCC put out a '.set nomacro' and because it tries to
put the two instructions generated by the macro into a delay slot.  My fix
is to generate 'lw' in 32 bit mode on loongson, then it doesn't generate a
macro and the instruction that is generated can go into a delay slot.

OK for checkin?


2013-08-12  Steve Ellcey  sell...@mips.com

* config/mips/mips.md (prefetch): Use lw instead of ld on
loongson in 32bit mode.


diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 397c40a..ad03040 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -6674,7 +6674,10 @@
 {
   if (TARGET_LOONGSON_2EF || TARGET_LOONGSON_3A)
 /* Loongson 2[ef] and Loongson 3a use load to $0 to perform prefetching.  
*/
-return ld\t$0,%a0;
+if (TARGET_64BIT)
+  return ld\t$0,%a0;
+else
+  return lw\t$0,%a0;
   operands[1] = mips_prefetch_cookie (operands[1], operands[2]);
   return pref\t%1,%a0;
 }

[patch, mips] Add nan2008 multilibs to mips-mti-* targets.

[Steve Ellcey]

I would like to add new variations to the mips-mti-elf and mips-mti-linux
targets to support the new NaN format on MIPS (mnan=2008 for IEEE 754-2008).
While I was doing this I noticed that I was handling mips16 and micromips
in a dumb manner.  I had them in MULTILIB_OPTIONS as non-exclusive flags
and then used MULTILIB_EXCEPTIONS to not allow them to both be used.
So I also changed MULTILIB_OPTIONS to make mips16 and micromips exclusive and
then I could get rid of one of the MULTILIB_EXCEPTIONS entries.  I also
make the new mnan=2008 flag exclusive of msoft-float since it is only
useful for hard-float.

OK to checkin?

Steve Ellcey
sell...@mips.com

2013-08-07  Steve Ellcey  sell...@mips.com

* config/mips/mti-linux.h (SYSROOT_SUFFIX_SPEC): Add nan2008.
* config/mips/t-mti-elf (MULTILIB_OPTIONS): Make mips16 and
micromips incompatible.  Add nan2008.
(MULTILIB_DIRNAMES): Add nan2008.
(MULTILIB_EXCEPTIONS): Remove mips16/micromips entry.
* config/mips/t-mti-linux (MULTILIB_OPTIONS): Make mips16
and micromips incompatible.  Add nan2008.
(MULTILIB_DIRNAMES): Add nan2008.
(MULTILIB_EXCEPTIONS): Remove mips16/micromips entry.


diff --git a/gcc/config/mips/mti-linux.h b/gcc/config/mips/mti-linux.h
index 45bc0b8..96dcac4 100644
--- a/gcc/config/mips/mti-linux.h
+++ b/gcc/config/mips/mti-linux.h
@@ -20,7 +20,7 @@ along with GCC; see the file COPYING3.  If not see
 /* This target is a multilib target, specify the sysroot paths.  */
 #undef SYSROOT_SUFFIX_SPEC
 #define SYSROOT_SUFFIX_SPEC \
-
%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mips16:/mips16}%{mmicromips:/micromips}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}
+
%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mips16:/mips16}%{mmicromips:/micromips}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}%{mnan=2008:/nan2008}
 
 #undef DRIVER_SELF_SPECS
 #define DRIVER_SELF_SPECS  \
diff --git a/gcc/config/mips/t-mti-elf b/gcc/config/mips/t-mti-elf
index bce8f06..4aec70c 100644
--- a/gcc/config/mips/t-mti-elf
+++ b/gcc/config/mips/t-mti-elf
@@ -19,8 +19,8 @@
 # The default build is mips32r2, hard-float big-endian.  Add mips32,
 # soft-float, and little-endian variations.
 
-MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mmicromips mabi=64 EL 
msoft-float
-MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof
+MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16/mmicromips mabi=64 EL 
msoft-float/mnan=2008
+MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof nan2008
 MULTILIB_MATCHES = EL=mel EB=meb
 
 # The 64 bit ABI is not supported on the mips32 architecture.
@@ -36,9 +36,7 @@ MULTILIB_EXCEPTIONS += mabi=64*
 MULTILIB_EXCEPTIONS += *mips64*/*mips16*
 MULTILIB_EXCEPTIONS += *mips16/mabi=64*
 
-# We only want micromips for mips32r2 architecture and we do not want
-# it used in conjunction with -mips16.
-MULTILIB_EXCEPTIONS += *mips16/mmicromips*
+# We only want micromips for mips32r2 architecture.
 MULTILIB_EXCEPTIONS += *mips64*/mmicromips*
 MULTILIB_EXCEPTIONS += *mips32/mmicromips*
 MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*
diff --git a/gcc/config/mips/t-mti-linux b/gcc/config/mips/t-mti-linux
index bce8f06..4aec70c 100644
--- a/gcc/config/mips/t-mti-linux
+++ b/gcc/config/mips/t-mti-linux
@@ -19,8 +19,8 @@
 # The default build is mips32r2, hard-float big-endian.  Add mips32,
 # soft-float, and little-endian variations.
 
-MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mmicromips mabi=64 EL 
msoft-float
-MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof
+MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16/mmicromips mabi=64 EL 
msoft-float/mnan=2008
+MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof nan2008
 MULTILIB_MATCHES = EL=mel EB=meb
 
 # The 64 bit ABI is not supported on the mips32 architecture.
@@ -36,9 +36,7 @@ MULTILIB_EXCEPTIONS += mabi=64*
 MULTILIB_EXCEPTIONS += *mips64*/*mips16*
 MULTILIB_EXCEPTIONS += *mips16/mabi=64*
 
-# We only want micromips for mips32r2 architecture and we do not want
-# it used in conjunction with -mips16.
-MULTILIB_EXCEPTIONS += *mips16/mmicromips*
+# We only want micromips for mips32r2 architecture.
 MULTILIB_EXCEPTIONS += *mips64*/mmicromips*
 MULTILIB_EXCEPTIONS += *mips32/mmicromips*
 MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*

Re: Passes are now C++ classes (was Re: [PATCH 03/11] Handwritten part of conversion of passes to C++ classes)

[Steve Ellcey]

On Mon, 2013-08-05 at 17:03 -0400, David Malcolm wrote:

 Given all of the above testing I'm reasonably confident that this works.
 However this is such a large change [1] that there's a non-zero chance
 of at least one glitch - let me know if you see any breakages.

The mips*-*-* targets are not building.  It looks like the mips reorg
pass (pass_mips_machine_reorg2) in config/mips/mips.c was not converted
and/or was not converted correctly.

Steve Ellcey
sell...@mips.com

Re: [patch, mips] Size savings for MIPS16 switch statements

[Steve Ellcey]

On Tue, 2013-07-30 at 11:18 +0100, Maciej W. Rozycki wrote:
 
 -- it may be that the tests have to be disabled at -Os just like e.g. 
 code-readable-1.c already is at -O0.
 
   Maciej

Sorry about that, not sure why I didn't notice the failures.  Rather
then skipping the tests for -Os I was thinking it might be better to
increase the size of the switch statements.  Here is a patch I have
tested to fix these failures.

Richard, does this look OK for checkin?

Steve Ellcey
sell...@mips.com


2013-07-30  Steve Ellcey  sell...@mips.com

* gcc.target/mips/code-readable-1.c: Increase switch size.
* gcc.target/mips/code-readable-2.c: Ditto.
* gcc.target/mips/code-readable-3.c: Ditto.
* gcc.target/mips/code-readable-4.c: Ditto.

diff --git a/gcc/testsuite/gcc.target/mips/code-readable-1.c 
b/gcc/testsuite/gcc.target/mips/code-readable-1.c
index 34c2c0a..b3e864d 100644
--- a/gcc/testsuite/gcc.target/mips/code-readable-1.c
+++ b/gcc/testsuite/gcc.target/mips/code-readable-1.c
@@ -8,6 +8,10 @@ volatile int x4;
 volatile int x5;
 volatile int x6;
 volatile int x7;
+volatile int x8;
+volatile int x9;
+volatile int x10;
+volatile int x11;
 
 MIPS16 int
 foo (int i, volatile *x)
@@ -21,6 +25,10 @@ foo (int i, volatile *x)
 case 5: return x5 + x[4];
 case 6: return x6 + x[5];
 case 7: return x7 + x[6];
+case 8: return x8 + x[7];
+case 9: return x9 + x[8];
+case 10: return x10 + x[9];
+case 11: return x11 + x[10];
 default: return 0;
 }
 }
diff --git a/gcc/testsuite/gcc.target/mips/code-readable-2.c 
b/gcc/testsuite/gcc.target/mips/code-readable-2.c
index 71aeb13..3d32504 100644
--- a/gcc/testsuite/gcc.target/mips/code-readable-2.c
+++ b/gcc/testsuite/gcc.target/mips/code-readable-2.c
@@ -7,6 +7,10 @@ volatile int x4;
 volatile int x5;
 volatile int x6;
 volatile int x7;
+volatile int x8;
+volatile int x9;
+volatile int x10;
+volatile int x11;
 
 MIPS16 int
 foo (int i, volatile *x)
@@ -20,6 +24,10 @@ foo (int i, volatile *x)
 case 5: return x5 + x[4];
 case 6: return x6 + x[5];
 case 7: return x7 + x[6];
+case 8: return x8 + x[7];
+case 9: return x9 + x[8];
+case 10: return x10 + x[9];
+case 11: return x11 + x[10];
 default: return 0;
 }
 }
diff --git a/gcc/testsuite/gcc.target/mips/code-readable-3.c 
b/gcc/testsuite/gcc.target/mips/code-readable-3.c
index fc78505..aaf1874 100644
--- a/gcc/testsuite/gcc.target/mips/code-readable-3.c
+++ b/gcc/testsuite/gcc.target/mips/code-readable-3.c
@@ -7,6 +7,10 @@ volatile int x4;
 volatile int x5;
 volatile int x6;
 volatile int x7;
+volatile int x8;
+volatile int x9;
+volatile int x10;
+volatile int x11;
 
 MIPS16 int
 foo (int i, volatile *x)
@@ -20,6 +24,10 @@ foo (int i, volatile *x)
 case 5: return x5 + x[4];
 case 6: return x6 + x[5];
 case 7: return x7 + x[6];
+case 8: return x8 + x[7];
+case 9: return x9 + x[8];
+case 10: return x10 + x[9];
+case 11: return x11 + x[10];
 default: return 0;
 }
 }
diff --git a/gcc/testsuite/gcc.target/mips/code-readable-4.c 
b/gcc/testsuite/gcc.target/mips/code-readable-4.c
index ae8ff8a..4db89f8 100644
--- a/gcc/testsuite/gcc.target/mips/code-readable-4.c
+++ b/gcc/testsuite/gcc.target/mips/code-readable-4.c
@@ -8,6 +8,10 @@ volatile int x4;
 volatile int x5;
 volatile int x6;
 volatile int x7;
+volatile int x8;
+volatile int x9;
+volatile int x10;
+volatile int x11;
 
 MIPS16 int
 foo (int i, volatile *x)
@@ -21,6 +25,10 @@ foo (int i, volatile *x)
 case 5: return x5 + x[4];
 case 6: return x6 + x[5];
 case 7: return x7 + x[6];
+case 8: return x8 + x[7];
+case 9: return x9 + x[8];
+case 10: return x10 + x[9];
+case 11: return x11 + x[10];
 default: return 0;
 }
 }

MIPS tests (nan-legacy.c and nans-legacy.c) failing

[Steve Ellcey]

Maciej,

When I run two of your new tests in gcc.target/mips (nan-legacy.c and
nans-legacy.c), they are failing because my GCC is putting out

.word   4294967295

instead of 

.word   -1

like the test is expecting.

I believe they are equivalent (0x) but I am not sure what it
is about my targets (mips-mti-elf and mips-mti-linux-gnu) that would
make this different from yours.  Should the tests be modified to allow
either output?

Steve Ellcey
sell...@mips.com

[patch, mips] Size savings for MIPS16 switch statements

[Steve Ellcey]

While doing some space optimization work with mips16 I found that using a
larger case threshold value could shrink the code.  I did testing on some
libraries like libpng and libjpeg as well as some test cases I wrote and
came up with 10 as the best value for space savings in mips16 mode.  I did
some testing of mips32 code as well and found that this change did not
help with that code so I restricted the change to mips16 only.

Tested on mips-mti-elf target, OK for checkin?

Steve Ellcey
sell...@mips.com



2013-07-23  Steve Ellcey  sell...@mips.com

* config/mips/mips.c (mips_case_values_threshold): New.
(TARGET_CASE_VALUES_THRESHOLD): Define.



diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index a3735dc..fb39f7c 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -18613,6 +18613,19 @@ mips_expand_vec_minmax (rtx target, rtx op0, rtx op1,
   x = gen_rtx_IOR (vmode, t0, t1);
   emit_insn (gen_rtx_SET (VOIDmode, target, x));
 }
+
+/* Implement `CASE_VALUES_THRESHOLD'.  */
+/* Supply the default for --param case-values-threshold=0  */
+
+unsigned int
+mips_case_values_threshold (void)
+{
+  /* In MIPS16 mode using a larger case threshold generates smaller code.  */
+  if (TARGET_MIPS16  optimize_size)
+return 10;
+  else
+return default_case_values_threshold ();
+}
 
 /* Initialize the GCC target structure.  */
 #undef TARGET_ASM_ALIGNED_HI_OP
@@ -18844,6 +18857,9 @@ mips_expand_vec_minmax (rtx target, rtx op0, rtx op1,
 #undef TARGET_VECTORIZE_VEC_PERM_CONST_OK
 #define TARGET_VECTORIZE_VEC_PERM_CONST_OK mips_vectorize_vec_perm_const_ok
 
+#undef TARGET_CASE_VALUES_THRESHOLD
+#define TARGET_CASE_VALUES_THRESHOLD mips_case_values_threshold
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include gt-mips.h

Re: RFA: Fix rtl-optimization/57425 (SPEC perl problem on MIPS)

[Steve Ellcey]

Joern,

Has anyone reported any problems to you about this patch?  I am running into
a problem running the perl benchmark from SPEC2006 and I have tracked it down
to this June 16 patch (SVN 200133,
GIT ddba76b84c757d93b4247713d558724776149b62).  I am building a GCC cross
compiler running on x86 linux and targeting mips-mti-linux-gnu.

I haven't been able to cut down perl into a smaller test case yet but starting
with this version of GCC, if I build perl with -O2 or -O3 and then run it with
this perl input:

% cat x.pl
#!./perl
{
eval {
use Math::BigInt;
$y = pack('w*', Math::BigInt::-new(50));
};
}
1;


I get:

% ./perlbench_base.sellcey_reload x.pl
*** Error in `./perlbench_base.sellcey_reload': malloc(): memory corruption 
(fast): 0x00642390 ***

and perl seems to go into an infinite loop.  Before your change perl
ran and exited cleanly.  I will try to create a smaller example but I wanted
to see if you (or someone else on gcc-patches) was seeing anything like
this on any other targets.

Steve Ellcey
sell...@mips.com

[patch, mips] Size optimization for MIPS

[Steve Ellcey]

While doing some size measurements and optimization I found that using the 
t0 through t7 registers on MIPS in MIPS16 mode resulted in larger code.  This
is because you cannot actually do any operations on these registers in MIPS16
mode but can only move data to or from them.  Compiling libraries like libjpeg
and libpng with this change saved about 1% in space.  I also ran coremark, the
space saving there was smaller and the performance slowdown was around 3% so
I made the change dependent on the optimize_size flag.

I tested the change with the mips-mti-elf, running the GCC testsuite with the
-mips16 and saw no regressions.  OK to checkin?

Steve Ellcey
sell...@mips.com


Steve Ellcey  sell...@mips.com

* config/mips/mips.c (mips_conditional_register_usage): Do not
use t[0-7] registers in MIPS16 mode when optimizing for size.


diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index bd1d10b..fb89aa8 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -17213,6 +17213,21 @@ mips_conditional_register_usage (void)
   fixed_regs[27] = call_used_regs[27] = 1;
   fixed_regs[30] = call_used_regs[30] = 1;
 
+  /* In MIPS16 mode using the $t registers for reload results in code
+ that is larger (and slightly faster) then if we do not use them so
+if optimizing for size, do not use them.  */
+  if (optimize_size)
+   {
+ fixed_regs[8] = call_used_regs[8] = 1;
+ fixed_regs[9] = call_used_regs[9] = 1;
+ fixed_regs[10] = call_used_regs[10] = 1;
+ fixed_regs[11] = call_used_regs[11] = 1;
+ fixed_regs[12] = call_used_regs[12] = 1;
+ fixed_regs[13] = call_used_regs[13] = 1;
+ fixed_regs[14] = call_used_regs[14] = 1;
+ fixed_regs[15] = call_used_regs[15] = 1;
+   }
+
   /* Do not allow HI and LO to be treated as register operands.
 There are no MTHI or MTLO instructions (or any real need
 for them) and one-way registers cannot easily be reloaded.  */

Re: [patch, mips] Size optimization for MIPS

[Steve Ellcey]

On Tue, 2013-07-09 at 18:25 +0100, Richard Sandiford wrote:

 
 That was always the case though.  These registers weren't enabled because
 you can do operations on them.  They were enabled because they should make
 ideal spill space.  Moves to and from these registers always take 2 bytes,
 whereas stack spills take either 2 or 4 bytes (as well as being slower).
 
 So it sounds like the problem is that the heuristics aren't tuned properly.
 Disabling the registers seems like papering over the problem rather than
 fixing it.  But since no-one is likely to do the work to fix the heuristics,
 that isn't a good enough reason to reject the patch.

Pre-LRA I don't think there was any good way to tell GCC to use a
register for reloads but not for anything else.  I think LRA does
support this and someone here has started looking at LRA but we haven't
come up with register class definitions that make LRA work better then
the existing setup (particularly in terms of MIPS16 object size).  Do
you know if anyone else has started looking at LRA on MIPS?

 Please combine this with the previous block though, since the comment here
 contradicts the comment there.  It would also be worth saying why you
 keep $24 (for CMP and CMPI) and $25 (for SVR4 PIC).

OK, I have done this (see attached new patch).

 Please also run some sanity checks for -mabi=eabi and functions that
 have 5+ arguments (all used) to make sure that they still work.
 
 Thanks,
 Richard

I built a MIPS GCC with newlib that could handle -mabi=eabi and ran the
GCC testsuite, it all looked good.  I am pretty sure the GCC testsuite
has tests with 5+ arguments but I did a couple of hand tests as well and
they also looked good.

Steve Ellcey
sell...@mips.com


Steve Ellcey  sell...@mips.com

* config/mips/mips.c (mips_conditional_register_usage): Do not
use t[0-7] registers in MIPS16 mode when optimizing for size.


diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index bd1d10b..4b5a62c 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -17199,10 +17199,16 @@ mips_conditional_register_usage (void)
 }
   if (TARGET_MIPS16)
 {
-  /* In MIPS16 mode, we permit the $t temporary registers to be used
-for reload.  We prohibit the unused $s registers, since they
+  /* In MIPS16 mode, we prohibit the unused $s registers, since they
 are call-saved, and saving them via a MIPS16 register would
-probably waste more time than just reloading the value.  */
+ probably waste more time than just reloading the value.
+
+ We permit the $t temporary registers when optimizing for speed
+but not when optimizing for space because using them results in
+code that is larger (but faster) then not using them.  We do
+allow $24 (t8) because it is used in CMP and CMPI instructions
+and $25 (t9) because it is used as the SVR4 PIC register.  */
+
   fixed_regs[18] = call_used_regs[18] = 1;
   fixed_regs[19] = call_used_regs[19] = 1;
   fixed_regs[20] = call_used_regs[20] = 1;
@@ -17212,6 +17218,17 @@ mips_conditional_register_usage (void)
   fixed_regs[26] = call_used_regs[26] = 1;
   fixed_regs[27] = call_used_regs[27] = 1;
   fixed_regs[30] = call_used_regs[30] = 1;
+  if (optimize_size)
+   {
+ fixed_regs[8] = call_used_regs[8] = 1;
+ fixed_regs[9] = call_used_regs[9] = 1;
+ fixed_regs[10] = call_used_regs[10] = 1;
+ fixed_regs[11] = call_used_regs[11] = 1;
+ fixed_regs[12] = call_used_regs[12] = 1;
+ fixed_regs[13] = call_used_regs[13] = 1;
+ fixed_regs[14] = call_used_regs[14] = 1;
+ fixed_regs[15] = call_used_regs[15] = 1;
+   }
 
   /* Do not allow HI and LO to be treated as register operands.
 There are no MTHI or MTLO instructions (or any real need

Patch ping: [patch, libgfortran, configure] Cross-compile support for libgfortran

[Steve Ellcey]

Ping...  These libgfortran changes are done the same way as libstdc++
so I hope they are OK.

Steve Ellcey
sell...@mips.com



From sell...@mips.com Tue Jun  4 12:49:55 2013

This patch allows me to build libgfortran for a cross-compiling toolchain
using newlib.  Currently the checks done by AC_CHECK_FUNCS_ONCE fail with
my toolchain because the compile/link fails due to the configure script not
using the needed linker script in the link command.  The check for with_newlib
is how libjava deals with the problem and it fixes my build problems.

My only concern is defining HAVE_STRTOLD, strtold exists in my newlib but
I am not sure if that is true for all newlib builds.  I didn't see any
flags that I could easily use to check for long double support in the
libgfortran configure.ac, but it seems to assume that the type exists.

OK to checkin?

Steve Ellcey
sell...@mips.com


2013-06-04  Steve Ellcey  sell...@mips.com

* configure.ac (AC_CHECK_FUNCS_ONCE): Put into if statement.

diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 7d97fed..4a00470 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -261,13 +261,27 @@ GCC_HEADER_STDINT(gstdint.h)
 AC_CHECK_MEMBERS([struct stat.st_blksize, struct stat.st_blocks, struct 
stat.st_rdev])
 
 # Check for library functions.
-AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
-ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \
-alarm access fork execl wait setmode execve pipe dup2 close \
-strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
-getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
-readlink getgid getpid getppid getuid geteuid umask getegid \
-secure_getenv __secure_getenv)
+if test x${with_newlib} = xyes; then +   # We are being configured with a 
cross compiler.  AC_REPLACE_FUNCS
+   # may not work correctly, because the compiler may not be able to
+   # link executables.
+   AC_DEFINE(HAVE_MKSTEMP, 1, [Define if you have mkstemp.])
+   AC_DEFINE(HAVE_STRTOF, 1, [Define if you have strtof.])
+   AC_DEFINE(HAVE_STRTOLD, 1, [Define if you have strtold.])
+   AC_DEFINE(HAVE_SNPRINTF, 1, [Define if you have snprintf.])
+   AC_DEFINE(HAVE_STRCASESTR, 1, [Define if you have strcasestr.])
+   AC_DEFINE(HAVE_VSNPRINTF, 1, [Define if you have vsnprintf.])
+   AC_DEFINE(HAVE_LOCALTIME_R, 1, [Define if you have localtime_r.])
+   AC_DEFINE(HAVE_GMTIME_R, 1, [Define if you have gmtime_r.])
+else
+   AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
+   ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname 
\
+   alarm access fork execl wait setmode execve pipe dup2 close \
+   strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
+   getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
+   readlink getgid getpid getppid getuid geteuid umask getegid \
+   secure_getenv __secure_getenv)
+fi
 
 # Check strerror_r, cannot be above as versions with two and three arguments 
exist
 LIBGFOR_CHECK_STRERROR_R

Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).

[Steve Ellcey]

On Fri, 2013-06-21 at 17:43 +0100, James Greenhalgh wrote:

 So to my mind, this is all far too tied up in pass ordering details to
 resolve. Given that all the threading opportunities for my patch are found
 in dom1 and how fragile the positioning of dom1 is, there is not a great
 deal I can do to modify the ordering.
 
 The biggest improvement I could find comes from rerunning pass_ch
 immediately after dom1, though I'm not sure what the cost of that
 would be.
 
 I wonder if you or others have any thoughts on what the right thing to
 do would be?
 
  I am not sure if path threading in general is turned off for -Os but it
  probably should be.
 
 I agree, jump threading is on at -Os, path threading should not be.
 
 Thanks,
 James

I think that since it seems to be more a space issue then a time issue,
the way you currently have it is reasonable.  As long as the
optimization does not happen at -Os then I think we can probably live
with the space increase.

Steve Ellcey
sell...@mips.com

[patch, mips] Fix switch statement for mips16 (PR target/56942)

[Steve Ellcey]

Steven and Richard,

I saw the email about the s390 switch statement

http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01026.html

and tested this patch on MIPS to see if using NEXT_INSN instead of
next_real_insn fixed PR 56942.  It did, so is this the right long
term fix for MIPS?  Is it OK to check it in?  Since Steven added
an assert in tablejump_p, I did not include any here, though I could
if we thought it was needed.

Steve Ellcey
sell...@mips.com


2013-06-19  Steve Ellcey  sell...@imgtec.com

PR target/56942
* config/mips/mips.md (casesi_internal_mips16_mode):
Use NEXT_INSN instead of next_real_insn.


diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index ce322d8..b832dda 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -5948,7 +5948,7 @@
(clobber (reg:SI MIPS16_T_REGNUM))]
   TARGET_MIPS16_SHORT_JUMP_TABLES
 {
-  rtx diff_vec = PATTERN (next_real_insn (operands[2]));
+  rtx diff_vec = PATTERN (NEXT_INSN (operands[2]));
 
   gcc_assert (GET_CODE (diff_vec) == ADDR_DIFF_VEC);
   

Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).

[Steve Ellcey]

On Wed, 2013-06-19 at 14:19 +0100, James Greenhalgh wrote:

 Please let me know if this fixes the performance issues you
 were seeing and if you have any other comments.
 
 FWIW I've bootstrapped and regression tested this version of
 the patch on x86_64 and ARM with no regressions.
 
 Thanks,
 James Greenhalgh


James,

This patch does give me the same performance as my original patch, so
that is excellent.  While testing it I noticed that the final executable
is larger with your patch then with mine.  Here are the sizes of the
bare-metal executables I created using the same flags I sent you
earlier, the first has no switch optimization, the second one uses my
plugin optimization, and the third uses your latest patch.  I haven't
looked into why the size difference for your patch and mine exists, do
you see a size difference on your platforms?  I am not sure if path
threading in general is turned off for -Os but it probably should be.

% ll -art coremark.fsf*elf
-rwxr-xr-x 1 sellcey src 413812 Jun 19 11:11 coremark.fsf.1.elf
-rwxr-xr-x 1 sellcey src 414676 Jun 19 11:11 coremark.fsf.2.elf
-rwxr-xr-x 1 sellcey src 416402 Jun 19 11:11 coremark.fsf.3.elf


Steve Ellcey
sell...@mips.com

Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).

[Steve Ellcey]

On Fri, 2013-06-14 at 00:08 +0100, James Greenhalgh wrote:

 I see only minor cosmetic differences (Placement of labels,
 numbering of labels) between the two generated assembly files.
 
 Perhaps you could share the flags you were using and I can try to
 figure out which paths I seem to be missing. If I can't find them,
 I'll happily revert to using your search strategy.
 
 Regards,
 James Greenhalgh

I am building a cross compiler running on x86_64 and targeting
mips-mti-elf.  I ran the compiler with:

-mips32r2 -EL -msoft-float -O3 -funroll-all-loops -finline-functions
-finline-limit=1000 -DRTEYAMON

With my version the compiler calls gimple_duplicate_sese_region from
duplicate_blocks 60 times.  With your patch it calls
gimple_duplicate_sese_region from duplicate_thread_path 16 times.

Steve Ellcey
sell...@mips.com

Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).

[Steve Ellcey]

On Fri, 2013-06-07 at 16:14 +0100, James Greenhalgh wrote:


 Beyond that, the path search code is modified from Steve's patch
 to only perform one depth first search, and the path copy code
 is modified to purge the region entry and exit edges for those
 which traditional jump-threading may consider.
 
 Opinions?
 
 Thanks,
 James Greenhalgh

Hi James,

I tried out your patch and I am not getting the speed up in
coremark that I got with my patch.  I wonder if restricting it
to one depth first search is the reason.  With my patch I was
able to completely get rid of the switch statement, but with
this patch it still exists.  Maybe we need an option to do
multiple searches?

Steve Ellcey
sell...@mips.com

RE: [patch, mips] Fix for PR target/56942

[Steve Ellcey]

Steven,

The assert has been in ToT for over a week now and I haven't seen any problems 
reported.
Is it time to move on to the next step?

Steve Ellcey
sell...@mips.com


From: Steven Bosscher [stevenb@gmail.com]
Sent: Wednesday, May 29, 2013 3:15 PM
To: Steve Ellcey; gcc-patches@gcc.gnu.org; Andrew Bennett; 
rdsandif...@googlemail.com
Subject: Re: [patch, mips] Fix for PR target/56942


OK for trunk?

If it causes any trouble, please file a PR and assign it to me.

And when the dust has settled, I can clean up the FIXME for
JUMP_TABLE_DATA in next_active_insn, and fix up the back ends.

Ciao!
Steven


  * rtlanal.c (tablejump_p): Expect table and label to be adjacent.

Index: rtlanal.c
===
--- rtlanal.c   (revision 199324)
+++ rtlanal.c   (working copy)
@@ -2711,6 +2711,7 @@ tablejump_p (const_rtx insn, rtx *labelp, rtx *tab
(table = next_active_insn (label)) != NULL_RTX
JUMP_TABLE_DATA_P (table))
 {
+  gcc_assert (table == NEXT_INSN (label));
   if (labelp)
*labelp = label;
   if (tablep)

[patch, mips] Micromips delay slot fix

[Steve Ellcey]

We found a bug in the micromips implementation where the branch delay slot
was not getting filled for micromips.  You can reproduce this with a program
that just has an empty main function.  Andrew Bennett created this fix for
it and we would like to check it in.  I am submitting it for Andrew since he
doesn't have write access.

OK to checkin?

2013-06-10  Andrew Bennett andrew.benn...@imgtec.com
Steve Ellcey  sell...@mips.com

* config/mips/mips.md (single_insn): Fix attribute for micromips.


diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 2fdc79d..f18ab50 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -704,7 +704,9 @@
 
 ;; Is it a single instruction?
 (define_attr single_insn no,yes
-  (symbol_ref (get_attr_length (insn) == (TARGET_MIPS16 ? 2 : 4)
+  (symbol_ref (((TARGET_MIPS16 || TARGET_MICROMIPS)
+ get_attr_length (insn) == 2)
+   || (!TARGET_MIPS16  get_attr_length (insn) == 4)
? SINGLE_INSN_YES : SINGLE_INSN_NO)))
 
 ;; Can the instruction be put into a delay slot?

Re: [patch, mips] Micromips delay slot fix

[Steve Ellcey]

On Mon, 2013-06-10 at 23:13 +0100, Maciej W. Rozycki wrote:
 On Mon, 10 Jun 2013, Steve Ellcey  wrote:
 
  We found a bug in the micromips implementation where the branch delay slot
  was not getting filled for micromips.  You can reproduce this with a program
  that just has an empty main function.  Andrew Bennett created this fix for
  it and we would like to check it in.  I am submitting it for Andrew since he
  doesn't have write access.
 
  Your fix aside shouldn't empty main expand simply to:
 
 jrc $ra
 
 ?  There's no delay slot there.

Sorry, it should have been 'main(void) {return 0; }.  Then you get (with
the patch):

j   $31
move$2,$0

instead of:

move$2,$0
j   $31


  diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
  index 2fdc79d..f18ab50 100644
  --- a/gcc/config/mips/mips.md
  +++ b/gcc/config/mips/mips.md
  @@ -704,7 +704,9 @@
   
   ;; Is it a single instruction?
   (define_attr single_insn no,yes
  -  (symbol_ref (get_attr_length (insn) == (TARGET_MIPS16 ? 2 : 4)
  +  (symbol_ref (((TARGET_MIPS16 || TARGET_MICROMIPS)
  + get_attr_length (insn) == 2)
  +   || (!TARGET_MIPS16  get_attr_length (insn) == 4)
  ? SINGLE_INSN_YES : SINGLE_INSN_NO)))
 
  Is it safe to assume an RTL insn whose length is 4 has only a single 
 machine instruction in the microMIPS mode?  What's the difference to the 
 MIPS16 instruction set here?
 
   Maciej

I think so, I don't know of any microMIPS RTL instructions whose length
is 4 that would not be a single instruction.  Maybe I should add
Catherine in to the discussion to see if she knows differently.

Steve Ellcey
sell...@mips.com

[patch, libgfortran, configure] Cross-compile support for libgfortran

[Steve Ellcey]

This patch allows me to build libgfortran for a cross-compiling toolchain
using newlib.  Currently the checks done by AC_CHECK_FUNCS_ONCE fail with
my toolchain because the compile/link fails due to the configure script not
using the needed linker script in the link command.  The check for with_newlib
is how libjava deals with the problem and it fixes my build problems.

My only concern is defining HAVE_STRTOLD, strtold exists in my newlib but
I am not sure if that is true for all newlib builds.  I didn't see any
flags that I could easily use to check for long double support in the
libgfortran configure.ac, but it seems to assume that the type exists.

OK to checkin?

Steve Ellcey
sell...@mips.com


2013-06-04  Steve Ellcey  sell...@mips.com

* configure.ac (AC_CHECK_FUNCS_ONCE): Put into if statement.

diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 7d97fed..4a00470 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -261,13 +261,27 @@ GCC_HEADER_STDINT(gstdint.h)
 AC_CHECK_MEMBERS([struct stat.st_blksize, struct stat.st_blocks, struct 
stat.st_rdev])
 
 # Check for library functions.
-AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
-ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \
-alarm access fork execl wait setmode execve pipe dup2 close \
-strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
-getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
-readlink getgid getpid getppid getuid geteuid umask getegid \
-secure_getenv __secure_getenv)
+if test x${with_newlib} = xyes; then +   # We are being configured with a 
cross compiler.  AC_REPLACE_FUNCS
+   # may not work correctly, because the compiler may not be able to
+   # link executables.
+   AC_DEFINE(HAVE_MKSTEMP, 1, [Define if you have mkstemp.])
+   AC_DEFINE(HAVE_STRTOF, 1, [Define if you have strtof.])
+   AC_DEFINE(HAVE_STRTOLD, 1, [Define if you have strtold.])
+   AC_DEFINE(HAVE_SNPRINTF, 1, [Define if you have snprintf.])
+   AC_DEFINE(HAVE_STRCASESTR, 1, [Define if you have strcasestr.])
+   AC_DEFINE(HAVE_VSNPRINTF, 1, [Define if you have vsnprintf.])
+   AC_DEFINE(HAVE_LOCALTIME_R, 1, [Define if you have localtime_r.])
+   AC_DEFINE(HAVE_GMTIME_R, 1, [Define if you have gmtime_r.])
+else
+   AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
+   ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname 
\
+   alarm access fork execl wait setmode execve pipe dup2 close \
+   strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
+   getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
+   readlink getgid getpid getppid getuid geteuid umask getegid \
+   secure_getenv __secure_getenv)
+fi
 
 # Check strerror_r, cannot be above as versions with two and three arguments 
exist
 LIBGFOR_CHECK_STRERROR_R

[patch, testsuite, cilk] Fix cilk tests for simulators

[Steve Ellcey]

A number of the new cilk tests in gcc/testsuite/c-c++-common/cilk-plus/AN
fail for me when run via the gnu simulator on mips.  The problem is that
the gnu simulator does not set up argc and argv.  After asking in the gdb
mailing list I believe this is an issue for multiple simulators on multiple
platforms.  Looking through the GCC testsuite I did not see any other tests
that looked at argc/argv so I would like to change these tests to not use
argc/argv either.  In some tests I added a define (IN_GCC_TESTSUITE) that
I set to 1 and then don't check argc if this is set, in others I just used
the constant value 1 instead of using argc and in one (where argc was being
changed) I replaced the use of argc with a local variable.

Tested on mips-mti-elf with the GNU simulator.

OK to checkin?


2013-06-03  Steve Ellcey  sell...@mips.com

* c-c++-common/cilk-plus/AN/array_test2.c: Do not check argc value.
* c-c++-common/cilk-plus/AN/array_test_ND.c: Ditto.
* c-c++-common/cilk-plus/AN/comma_exp.c: Ditto.
* c-c++-common/cilk-plus/AN/if_test.c: Ditto.
* c-c++-common/cilk-plus/AN/conditional.c:  Replace argc with const 1.
* c-c++-common/cilk-plus/AN/sec_reduce_return.c: Ditto.
* c-c++-common/cilk-plus/AN/test_builtin_return.c: Ditto.
* c-c++-common/cilk-plus/AN/exec-once2.c: Replace argc with local var.


diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test2.c 
b/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test2.c
index bd7a4ad..178bba6 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test2.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test2.c
@@ -1,12 +1,12 @@
 /* { dg-do run } */
-/* { dg-options -fcilkplus } */
+/* { dg-options -fcilkplus -DIN_GCC_TESTSUITE=1 } */
 
 #include stdlib.h
 int main2(int argc, char **argv);
 int main(int argc, char **argv)
 {
   int x = 0;
-  if (argc == 1)
+  if (argc == 1 || IN_GCC_TESTSUITE)
 {
   const char *array[] = {a.out, 5}; 
   x = main2 (2, (char **)array);
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test_ND.c 
b/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test_ND.c
index 1431c22..441342b 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test_ND.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test_ND.c
@@ -1,12 +1,12 @@
 /* { dg-do run } */
-/* { dg-options -fcilkplus } */
+/* { dg-options -fcilkplus -DIN_GCC_TESTSUITE=1 } */
 
 #include stdlib.h
 int main2(int argc, char **argv);
 int main(int argc, char **argv)
 {
   int x = 0;
-  if (argc == 1)
+  if (argc == 1 || IN_GCC_TESTSUITE)
 {
   const char *array[] = {a.out, 10, 15};  
   x = main2 (3, (char **)array);
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c 
b/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c
index bcb3e1b..43138bb 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-options -fcilkplus } */
+/* { dg-options -fcilkplus -DIN_GCC_TESTSUITE } */
 
 #include stdlib.h
 
@@ -7,7 +7,7 @@ int main2 (int argc, char **argv);
 int main(int argc, char **argv)
 {
   int x = 0;
-  if (argc == 1)
+  if (argc == 1 || IN_GCC_TESTSUITE)
 {
   const char *array[] = {a.out, 5}; 
   x = main2 (2, (char **)array);
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/conditional.c 
b/gcc/testsuite/c-c++-common/cilk-plus/AN/conditional.c
index 0be99b2..4345a26 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/conditional.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/conditional.c
@@ -31,7 +31,7 @@ int main(int argc, char **argv)
 array[ii] = 3; 
   }
   array3 = (short *) malloc (sizeof (short) * 1000);
-  array3[0:1000:argc] = cond[:] ? array[0:(argc * 1000)] : array2[argc-1:1000];
+  array3[0:1000:1] = cond[:] ? array[0:(1 * 1000)] : array2[0:1000];
   
   for (ii = 0; ii  1000; ii++) {
 if ((cond[ii] == 0  array3[ii] != 5) 
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/exec-once2.c 
b/gcc/testsuite/c-c++-common/cilk-plus/AN/exec-once2.c
index 8d208b9..6cbfb66 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/exec-once2.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/exec-once2.c
@@ -34,23 +34,23 @@ int func4(int x)
 }
 
 
-/* This program makes an assumption that argc == 1.  */
 int main (int argc, char **argv)
 {
 
   int array[2500];
+  int i = 1;
 
   /* This should set array[0-999] to 5.  */
-  array[argc-1:func2(++argc):1] = 5;
+  array[i-1:func2(++i):1] = 5;
   array[1000:500:1] = 10; /* set all variables in array[1000--1499] to 10.  */
   array[1500:500:1] = 15; /* set all variables in array[1500--1999] to 15.  */
   array[2000:500:1] = 20; /* set all variables in array[2000--2499] to 20.  */
   array[2000:500:1] = 25; /* set all variables in array[2500--2999] to 25.  */
   array[2000:500:1] = 30; /* set all variables in array[3000--3499] to 30.  */
   
-  argc = func3 (argc

Re: [patch, testsuite, cilk] Fix cilk tests for simulators

[Steve Ellcey]

On Mon, 2013-06-03 at 13:47 -0600, Jeff Law wrote:
 On 06/03/2013 01:27 PM, Iyer, Balaji V wrote:
 
  I am OK with Steve's changes in most cases. In a few cases, I am
  using it as a parameter to pass into tests. On a top-level, the main
  reason why I used argc, and argv is that, I want to make sure the
  compiler will never do things like constant propagation, and it will
  pass it as a variable.
 So use Jakub's trick, or define non-inlinable functions which return 
 suitable tables.
 
 We simply can't use argc/argv in the manner in which those tests do and 
 I'd rather clean up the test to avoid argc/argv than support two paths 
 through the test, one with argc/argv, one without.
 
 jeff

I'll leave fixing the tests to Balaji then instead of doing it myself
since that way he can be sure that they are testing what he wants to
test.

Steve Ellcey
sell...@mips.com

Re: [patch, mips] Fix for PR target/56942

[Steve Ellcey]

On Thu, 2013-05-30 at 00:15 +0200, Steven Bosscher wrote:

 And I can't get it to fail. I also can't find any place where the
 label and jump table might get separated. I was expecting some trouble
 with cross-jumping but it seems that it takes care of updating the
 label reference, and skip_insns_after_block already expects the label
 and table to be adjacent.
 
 So let's just see if/what breaks...
 
 Bootstrappedtested on powerpc64-unknown-linux-gnu (unix{,-m32}).
 Bootstrappedtested on x86_64-unknown-linux-gnu (unix{,-m32}).
 Buildtested powerpc64 X mips-elf.

I tested this with mips-mti-linux-gnu and mips-mti-elf by building cross
compilers and testing and I did not hit the assert either.

Steve Ellcey
sell...@imgtec.com

Re: [patch] Default to --enable-libstdcxx-time=auto

[Steve Ellcey]

On Wed, 2013-05-22 at 09:14 +0100, Jonathan Wakely wrote:
 This alters the configure script to enable C++11 thread library
 features based on targets that are known to support the features,
 rather than based on link tests which are disabled by default.  With
 Glibc 2.17 this enables a nanosecond resolution std::system_clock in
 the default configuration, yay!
 
 I've tested this on two versions of Fedora and Debian, but would be
 grateful for test results on Solaris, Cygwin and BSD targets, and for
 cross-compilers to any of those targets.
 
 * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add KIND=auto to
 enable features if target OS is known to support them.
 * configure.ac (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Default to 'auto'.
 * configure: Regenerate.
 
 
 Tested x86_64-linux, committed to trunk.

Jonathan,

This has broken the mips-mti-elf build for me, this target uses newlib
and I am building with the latest newlib sources as well as the latest
GCC sources.  I don't know if this is related to the problem that others
have had or not.  I saw emails about test failures but not about build
failures.  The problem I get when building a x86 to mips cross compiler
is:

/local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:
 In static member function 'static std::chrono::system_clock::time_point 
std::chrono::system_clock::now()':
/local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:81:14:
 error: 'from_time_t' is not a member of 'std::chrono::system_clock'
   return system_clock::from_time_t(__sec);
  ^
/local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:83:5:
 warning: control reaches end of non-void function [-Wreturn-type]
 }

I will dig around some more but I thought I would see if you had any
ideas on what the problem was and how to fix it.

Steve Ellcey
sell...@imgtec.com

Re: [patch] Default to --enable-libstdcxx-time=auto

[Steve Ellcey]

On Tue, 2013-05-28 at 17:29 +0100, Jonathan Wakely wrote:

 
 I don't think it was my patch that broke it, because
 compatibility-chrono.cc didn't exist when my patch went in  :-)

Sorry about that, I guess I got lost in a maze of twisty checkins.

 Does this help?
 
 --- src/c++11/compatibility-chrono.cc.orig  2013-05-28
 17:27:54.631919423 +0100
 +++ src/c++11/compatibility-chrono.cc   2013-05-28 17:28:43.697861786 +0100
 @@ -78,7 +78,9 @@
  + chrono::microseconds(tv.tv_usec)));
  #else
std::time_t __sec = std::time(0);
 -  return system_clock::from_time_t(__sec);
 +  typedef chrono::time_pointsystem_clock, seconds__from;
 +  return time_point_castsystem_clock::duration
 +  (__from(chrono::seconds(__sec)));
  #endif
  }

Yes, it does.  My build worked fine after applying this patch to my
local tree.

Steve Ellcey
sell...@imgtec.com

Re: [patch, mips] Patch for mips generic scheduler

[Steve Ellcey]

On Wed, 2013-05-22 at 07:30 +0100, Richard Sandiford wrote:

 Oops -- only if someone submitted one :-)  So we should definitely
 change the mips32r2 entry.  I'd suggest one of PROCESSOR_24KF* or
 PROCESSOR_74KF*, so that we get the FPU scheduling, but I don't know
 which would be more representative of the general case.  TUNE_74*
 has quite a lot of special code associated with it, whereas TUNE_24*
 sets TUNE_MACC_CHAINS, which might overemphasise the use of MADD
 for 74k targets when -mimadd is used.
 
 But any choice is going to be a compromise.  A patch to do either
 is preapproved.
 
 Thanks,
 Richard

OK, I did some testing and benchmarking and did not find a clear best
choice so I think I will go with PROCESSOR_74KF2_1.  Here is the patch
I will check in shortly:



2013-05-28  Steve Ellcey  sell...@mips.com

* config/mips/mips-cpus.def (mips32r2): Change processor type.



diff --git a/gcc/config/mips/mips-cpus.def
b/gcc/config/mips/mips-cpus.def
index 9e5fd16..f08fad6 100644
--- a/gcc/config/mips/mips-cpus.def
+++ b/gcc/config/mips/mips-cpus.def
@@ -43,7 +43,7 @@ MIPS_CPU (mips4, PROCESSOR_R8000, 4, 0)
that to a recommendation to avoid the instructions in code that
isn't tuned to a specific processor.  */
 MIPS_CPU (mips32, PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY)
-MIPS_CPU (mips32r2, PROCESSOR_M4K, 33, PTF_AVOID_BRANCHLIKELY)
+MIPS_CPU (mips32r2, PROCESSOR_74KF2_1, 33, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU (mips64, PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY)
 /* ??? For now just tune the generic MIPS64r2 for 5KC as well.   */
 MIPS_CPU (mips64r2, PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY)

[patch, mips] Update multilibs for mips-mti-* targets

[Steve Ellcey]

Richard,

This patch adds the micromips multilib to the mips-mti-elf and mips-mti-linux
targets.  It also adds mips16 multilib to mips-mti-linux.  I hadn't added
that earlier because I was waiting for the mips16 changes to get checked in
to glibc and they are in now.  It shouldn't affect any other mips targets,
OK to checkin?

Steve Ellcey
sell...@imgtec.com


2013-05-28  Steve Ellcey  sell...@imgtec.com

* config/mips/mti-linux.h (SYSROOT_SUFFIX_SPEC): Add micromips
and mips16 directories.
* config/mips/t-mti-linux (MULTILIB_OPTIONS): Add micromips and
mips16.
(MULTILIB_DIRNAMES): Ditto.
(MULTILIB_EXCEPTIONS): Add new exceptions.
* config/mips/t-mti-elf (MULTILIB_OPTIONS): Add micromips.
(MULTILIB_DIRNAMES): Ditto.
(MULTILIB_EXCEPTIONS): Add new exceptions.


diff --git a/gcc/config/mips/mti-linux.h b/gcc/config/mips/mti-linux.h
index a3fb489..45bc0b8 100644
--- a/gcc/config/mips/mti-linux.h
+++ b/gcc/config/mips/mti-linux.h
@@ -20,7 +20,7 @@ along with GCC; see the file COPYING3.  If not see
 /* This target is a multilib target, specify the sysroot paths.  */
 #undef SYSROOT_SUFFIX_SPEC
 #define SYSROOT_SUFFIX_SPEC \
-
%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}
+
%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mips16:/mips16}%{mmicromips:/micromips}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}
 
 #undef DRIVER_SELF_SPECS
 #define DRIVER_SELF_SPECS  \
diff --git a/gcc/config/mips/t-mti-elf b/gcc/config/mips/t-mti-elf
index 3f0868f..66b6cbd 100644
--- a/gcc/config/mips/t-mti-elf
+++ b/gcc/config/mips/t-mti-elf
@@ -16,8 +16,8 @@
 # along with GCC; see the file COPYING3.  If not see
 # http://www.gnu.org/licenses/.
 
-MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mabi=64 EL msoft-float
-MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 64 el sof
+MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mmicromips mabi=64 EL 
msoft-float
+MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof
 MULTILIB_MATCHES = EL=mel EB=meb
 
 # We do not want to build mips16 versions of mips64* architectures.
@@ -32,4 +32,11 @@ MULTILIB_EXCEPTIONS += *mips32*/*mabi=64*
 # or mips64r2 but does specify mabi=64 is not allowed because that
 # would be defaulting to the mips32r2 architecture.
 MULTILIB_EXCEPTIONS += mabi=64*
-MULTILIB_EXCEPTIONS += mips16/mabi=64*
+MULTILIB_EXCEPTIONS += *mips16/mabi=64*
+MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*
+
+# We only want micromips for mips32r2 architecture and we do not want
+# it used in conjunction with -mips16.
+MULTILIB_EXCEPTIONS += *mips16/mmicromips*
+MULTILIB_EXCEPTIONS += *mips64*/mmicromips*
+MULTILIB_EXCEPTIONS += *mips32/mmicromips*
diff --git a/gcc/config/mips/t-mti-linux b/gcc/config/mips/t-mti-linux
index 775a68d..3d99e25 100644
--- a/gcc/config/mips/t-mti-linux
+++ b/gcc/config/mips/t-mti-linux
@@ -19,15 +19,26 @@
 # The default build is mips32r2, hard-float big-endian.  Add mips32,
 # soft-float, and little-endian variations.
 
-MULTILIB_OPTIONS = mips32/mips64/mips64r2 mabi=64 EL msoft-float
-MULTILIB_DIRNAMES = mips32 mips64 mips64r2 64 el sof
+MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mmicromips mabi=64 EL 
msoft-float
+MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof
 MULTILIB_MATCHES = EL=mel EB=meb
 
+# We do not want to build mips16 versions of mips64* architectures.
+MULTILIB_EXCEPTIONS += *mips64*/*mips16*
+
 # The 64 bit ABI is not supported on the mips32 architecture.
 MULTILIB_EXCEPTIONS += *mips32*/*mabi=64*
 
 # The 64 bit ABI is not supported on the mips32r2 architecture.
 # Because mips32r2 is the default we can't use that flag to trigger
-# the exception so we check for mabi=64 with no specific mips flag
-# instead.
+# the exception so we check for mabi=64 with no specific mips
+# architecture flag instead.
 MULTILIB_EXCEPTIONS += mabi=64*
+MULTILIB_EXCEPTIONS += *mips16/mabi=64*
+MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*
+
+# We only want micromips for mips32r2 architecture and we do not want
+# it used in conjunction with -mips16.
+MULTILIB_EXCEPTIONS += *mips16/mmicromips*
+MULTILIB_EXCEPTIONS += *mips64*/mmicromips*
+MULTILIB_EXCEPTIONS += *mips32/mmicromips*

Re: [patch, mips] Patch for mips generic scheduler

[Steve Ellcey]

On Tue, 2013-05-21 at 19:55 +0100, Richard Sandiford wrote:

 Hmm, but generic.md is very much legacy and shouldn't be used for
 vaguely modern cores.  Even something like -mips32 is supposed to avoid
 the generic scheduler; it should use the 4k scheduler instead.
 What options were you using to trigger it?

I am just doing a default compilation of my mips-mti-linux-gnu target.
This defaults to mips32r2.  I just tried adding -mtune=mips32r2 and that
made no difference, -mtune=4k also makes no difference, but -mtune=4kc
does affect the output.

 It might be worth having a new generic scheduler that's supposed to be
 a good compromise for modern cores though.  Or, more simply, we could just
 change:
 
 MIPS_CPU (mips32, PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU (mips32r2, PROCESSOR_M4K, 33, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU (mips64, PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY)
 /* ??? For now just tune the generic MIPS64r2 for 5KC as well.   */
 MIPS_CPU (mips64r2, PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY)
 
 to tune for other processors instead, if you don't think 4kc, etc. are
 representative enough.

Hm, I think the problem may be that mips32r2 defaults to PROCESSOR_M4K
and mips32 defaults to PROCESSOR_4KC.  I don't see any special scheduler
for m4k.  Is there supposed to be a scheduler for m4k?

Steve Ellcey

Re: [PATCH][gensupport] Add optional attributes field to define_cond_exec

[Steve Ellcey]

On Mon, 2013-05-20 at 17:55 +0100, Kyrylo Tkachov wrote:

 I've been working and testing on the arm backend, however I noticed that
 ia64 and c6x use define_cond_exec as well,
 so I'm cc'ing Steve. Would it be possible for you to confirm that this
 doesn't break ia64?

I am not at HP anymore and don't have access to any IA64 boxes (other
than the one in the GCC compile farm), so I don't think I can confirm
this for you.

Steve Ellcey
sell...@imgtec.com

[patch, mips] Patch for mips generic scheduler

[Steve Ellcey]

While looking at some matrix code I noticed that the generic mips scheduler
was putting out a bunch of integer madd instructions in a row and that
I got better performance (on 74kc and proAptiv) when they were spread out.

I was wondering what folks thought of this change to specify that the
integer madd instruction uses the alu and the imuldiv functional units?

Tested on 74kc and proAptive with no regressions and better performance.

OK to checkin?

Steve Ellcey
sell...@imgtec.com



2013-05-20  Steve Ellcey  sell...@imgtec.com

* config/mips/generic.md (generic_imul): Remove imadd.
(generic_imadd): New.


diff --git a/gcc/config/mips/generic.md b/gcc/config/mips/generic.md
index 6051630..f187e0b 100644
--- a/gcc/config/mips/generic.md
+++ b/gcc/config/mips/generic.md
@@ -47,9 +47,13 @@
   imuldiv*3)
 
 (define_insn_reservation generic_imul 17
-  (eq_attr type imul,imul3,imadd)
+  (eq_attr type imul,imul3)
   imuldiv*17)
 
+(define_insn_reservation generic_imadd 17
+  (eq_attr type imadd)
+  (alu+imuldiv)*17)
+
 (define_insn_reservation generic_idiv 38
   (eq_attr type idiv)
   imuldiv*38)

Re: [PATCH] New switch optimization pass (PR tree-optimization/54742)

[Steve Ellcey]

On Thu, 2013-05-16 at 10:58 +0200, Richard Biener wrote:

 
  Hmm, not terribly happy with that wording, but that gives you an idea of
  what I'm after.  When would someone set UPDATE_DOMINANCE to true and what
  are their responsibilities when they do so.
 
  Approved with the name change and a better comment for UPDATE_DOMINANCE.
 
 Btw, the function does _not_ handle arbitrary SEME regions - it only handles
 a single exit correctly and assumes no (SSA) data flows across the others.
 So I'd rather not rename it.
 
 Richard.
 
  Jeff

I went ahead and checked in the change with the comment updates that
Jeff wanted but left the name of the function as is.

Steve Ellcey
sell...@imgtec.com

Re: [PATCH] New switch optimization pass (PR tree-optimization/54742)

[Steve Ellcey]

On Wed, 2013-05-15 at 10:44 +0200, Richard Biener wrote:

 Indeed.  I'd rather have a flag to the SESE copier that tells it the region
 is SEME and in that case make it not update dominators but leave that
 to the caller (which means, recompute them).  It seems the code already
 handles ME regions if the other exits are not important (we don't have
 to insert/update PHI nodes in those exit blocks), so it may be that there
 are even more constraints on those unimportant exits due to the
 iterative dominator update - I think that the entry block of the region
 needs to dominate all exit destinations, otherwise get_dominated_by_region
 is not working correctly.  In your case one exit is a back-edge?  We should
 be able to add checking to the code to verify unimportant edges are
 unimportant enough.
 
 I'm sure Zdenek knows the limitations best.
 
 Richard.

Here is a patch that adds a flag to gimple_duplicate_sese_region to tell
it whether or not to update the dominator information.  I had to add the
same flag to copy_bbs to make it all work.  How does this look?  I
tested it with a bootstrap and test on x86 (with my optimization
enabled) and got no regressions.

2013-05-15  Steve Ellcey  sell...@imgtec.com

* cfghooks.c (copy_bbs): Add update_dominance argument.
* cfghooks.h (copy_bbs): Update prototype.
* tree-cfg.c (gimple_duplicate_sese_region):
Add update_dominance argument.
* tree-flow.h (gimple_duplicate_sese_region): Update prototype.
* tree-ssa-loop-ch.c (copy_loop_headers): Update
gimple_duplicate_sese_region call.
* tree-vect-loop-manip.c (slpeel_tree_duplicate_loop_to_edge_cfg):
Update copy_bbs call.
* cfgloopmanip.c (duplicate_loop_to_header_edge): Ditto.
* trans-mem.c (ipa_uninstrument_transaction): Ditto.

diff --git a/gcc/cfghooks.c b/gcc/cfghooks.c
index 22b962b..18af38b 100644
--- a/gcc/cfghooks.c
+++ b/gcc/cfghooks.c
@@ -1287,7 +1287,8 @@ end:
function assigns bbs into loops (copy of basic block bb is assigned to
bb-loop_father-copy loop, so this must be set up correctly in advance)
and updates dominators locally (LOOPS structure that contains the 
information
-   about dominators is passed to enable this).
+   about dominators is passed to enable this) if update_dominance is set to
+   true.
 
BASE is the superloop to that basic block belongs; if its header or latch
is copied, we do not set the new blocks as header or latch.
@@ -1301,7 +1302,7 @@ end:
 void
 copy_bbs (basic_block *bbs, unsigned n, basic_block *new_bbs,
  edge *edges, unsigned num_edges, edge *new_edges,
- struct loop *base, basic_block after)
+ struct loop *base, basic_block after, bool update_dominance)
 {
   unsigned i, j;
   basic_block bb, new_bb, dom_bb;
@@ -1327,16 +1328,19 @@ copy_bbs (basic_block *bbs, unsigned n, basic_block 
*new_bbs,
 }
 
   /* Set dominators.  */
-  for (i = 0; i  n; i++)
+  if (update_dominance)
 {
-  bb = bbs[i];
-  new_bb = new_bbs[i];
-
-  dom_bb = get_immediate_dominator (CDI_DOMINATORS, bb);
-  if (dom_bb-flags  BB_DUPLICATED)
+  for (i = 0; i  n; i++)
{
- dom_bb = get_bb_copy (dom_bb);
- set_immediate_dominator (CDI_DOMINATORS, new_bb, dom_bb);
+ bb = bbs[i];
+ new_bb = new_bbs[i];
+
+ dom_bb = get_immediate_dominator (CDI_DOMINATORS, bb);
+ if (dom_bb-flags  BB_DUPLICATED)
+   {
+ dom_bb = get_bb_copy (dom_bb);
+ set_immediate_dominator (CDI_DOMINATORS, new_bb, dom_bb);
+   }
}
 }
 
diff --git a/gcc/cfghooks.h b/gcc/cfghooks.h
index bff0a0c..ec595a5 100644
--- a/gcc/cfghooks.h
+++ b/gcc/cfghooks.h
@@ -201,7 +201,7 @@ extern void lv_add_condition_to_bb (basic_block, 
basic_block, basic_block,
 extern bool can_copy_bbs_p (basic_block *, unsigned);
 extern void copy_bbs (basic_block *, unsigned, basic_block *,
  edge *, unsigned, edge *, struct loop *,
- basic_block);
+ basic_block, bool);
 
 void account_profile_record (struct profile_record *, int);
 
diff --git a/gcc/cfgloopmanip.c b/gcc/cfgloopmanip.c
index 9581677..bc87755 100644
--- a/gcc/cfgloopmanip.c
+++ b/gcc/cfgloopmanip.c
@@ -1300,7 +1300,7 @@ duplicate_loop_to_header_edge (struct loop *loop, edge e,
 
   /* Copy bbs.  */
   copy_bbs (bbs, n, new_bbs, spec_edges, 2, new_spec_edges, loop,
-   place_after);
+   place_after, true);
   place_after = new_spec_edges[SE_LATCH]-src;
 
   if (flags  DLTHE_RECORD_COPY_NUMBER)
diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c
index 5cb8286..c66278c 100644
--- a/gcc/trans-mem.c
+++ b/gcc/trans-mem.c
@@ -3978,7 +3978,8 @@ ipa_uninstrument_transaction (struct tm_region *region,
   int n = queue.length ();
   basic_block *new_bbs = XNEWVEC (basic_block, n);
 
-  copy_bbs (queue.address (), n, new_bbs, NULL, 0, NULL, NULL

Re: [patch] Hash table changes from cxx-conversion branch - config part

[Steve Ellcey]

On Mon, 2013-05-13 at 15:03 -0700, Lawrence Crowl wrote:
 I still have not heard from i386 or ia64 folks.  Anyone?

The IA64 part looks OK to me.

Steve Ellcey
sell...@imgtec.com (sell...@mips.com)

Re: [PATCH] New switch optimization pass (PR tree-optimization/54742)

[Steve Ellcey]

While Jeff works on the threader, I was wondering if I could get approval for
just the dominance.c part of the patch.  This would allow me to use my pass as
a dynamically loaded optimization pass.  But without this change to dominance.c,
the compiler aborts in iterate_fix_dominators when I do that.

Steve Ellcey
sell...@imgtec.com



2013-05-14  Steve Ellcey  sell...@imgtec.com

* dominance.c (iterate_fix_dominators): Add null check.


diff --git a/gcc/dominance.c b/gcc/dominance.c
index 5c96dad..d858ad1 100644
--- a/gcc/dominance.c
+++ b/gcc/dominance.c
@@ -1251,6 +1251,7 @@ iterate_fix_dominators (enum cdi_direction dir, 
vecbasic_block bbs,
   struct pointer_map_t *map;
   int *parent, *son, *brother;
   unsigned int dir_index = dom_convert_dir_to_idx (dir);
+  void **slot;
 
   /* We only support updating dominators.  There are some problems with
  updating postdominators (need to add fake edges from infinite loops
@@ -1357,7 +1358,10 @@ iterate_fix_dominators (enum cdi_direction dir, 
vecbasic_block bbs,
  if (dom == bb)
continue;
 
- dom_i = (size_t) *pointer_map_contains (map, dom);
+ slot = pointer_map_contains (map, dom);
+ if (slot == NULL)
+   continue;
+ dom_i = (size_t) *slot;
 
  /* Do not include parallel edges to G.  */
  if (!bitmap_set_bit ((bitmap) g-vertices[dom_i].data, i))

[PATCH] New switch optimization pass (PR tree-optimization/54742)

[Steve Ellcey]

Here is the latest version of my SSA optimization pass to do the switch
statement optimization described in PR 54742 (core_state_transition from
coremark).

I have tested this optimization with a x86 bootstrap and GCC test run
with no errors and tested the MIPS cross compiler with no errors.
Because of that I decided to submit it as a statically linked
optimization pass instead of a dynamically loaded one, though I did keep
the ifdefs for using it as a dynamic pass in the code.  They could be
removed if this patch is approved as a statically linked pass.  Also,
while this patch shows the optimization only being turned on with the
-ftree-switch-shortcut flag, my bootstrap and testing had it turned on
for all -O2 optimizations in order to maximize the testing.
We may want to turn this on for -O3 and/or for
-fexpensive-optimizations.

I had to make one change to dominance.c in order to avoid some compiler
aborts where it was dereferencing a null pointer.  I believe this was
happening because I am calling gimple_duplicate_sese_region with regions
that are not really SESE.  Because I am doing this, I regenerate the cfg
and SSA information after each call, but I also had to change
iterate_fix_dominators to fix the abort.  Another way we might want to
fix this would be to pass a flag to gimple_duplicate_sese_region that
tells it whether or not we want it to recalculate the dominance
information at all.  If set to false, it would assume the caller will
take care of it.

Opinions?  OK to checkin?

Steve Ellcey
sell...@imgtec.com


2013-05-13  Steve Ellcey  sell...@imgtec.com

PR tree-optimization/54742
* Makefile.in (OBJS): Add tree-switch-shortcut.o.
* common.opt (ftree-switch-shortcut): New.
* dominance.c (iterate_fix_dominators): Add null check.
* params.def (PARAM_MAX_SWITCH_INSNS): New.
(PARAM_MAX_SWITCH_PATHS): New.
* passes.c (init_optimization_passes): Add pass_switch_shortcut.
* timevar.def (TV_SWITCH_SHORTCUT): New.
* tree-pass.c (pass_switch_shortcut): New.
* tree-switch-shortcut.c: New file.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 903125e..db0ffcb 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1399,6 +1399,7 @@ OBJS = \
 	tree-scalar-evolution.o \
 	tree-sra.o \
 	tree-switch-conversion.o \
+	tree-switch-shortcut.o \
 	tree-ssa-address.o \
 	tree-ssa-alias.o \
 	tree-ssa-ccp.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index 4c7933e..e028e2d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2160,6 +2160,10 @@ ftree-sra
 Common Report Var(flag_tree_sra) Optimization
 Perform scalar replacement of aggregates
 
+ftree-switch-shortcut
+Common Report Var(flag_tree_switch_shortcut) Init(0) Optimization
+Do fancy switch statement shortcutting
+
 ftree-ter
 Common Report Var(flag_tree_ter) Optimization
 Replace temporary expressions in the SSA-normal pass
diff --git a/gcc/dominance.c b/gcc/dominance.c
index 5c96dad..d858ad1 100644
--- a/gcc/dominance.c
+++ b/gcc/dominance.c
@@ -1251,6 +1251,7 @@ iterate_fix_dominators (enum cdi_direction dir, vecbasic_block bbs,
   struct pointer_map_t *map;
   int *parent, *son, *brother;
   unsigned int dir_index = dom_convert_dir_to_idx (dir);
+  void **slot;
 
   /* We only support updating dominators.  There are some problems with
  updating postdominators (need to add fake edges from infinite loops
@@ -1357,7 +1358,10 @@ iterate_fix_dominators (enum cdi_direction dir, vecbasic_block bbs,
 	  if (dom == bb)
 	continue;
 
-	  dom_i = (size_t) *pointer_map_contains (map, dom);
+	  slot = pointer_map_contains (map, dom);
+	  if (slot == NULL)
+	continue;
+	  dom_i = (size_t) *slot;
 
 	  /* Do not include parallel edges to G.  */
 	  if (!bitmap_set_bit ((bitmap) g-vertices[dom_i].data, i))
diff --git a/gcc/params.def b/gcc/params.def
index 3c52651..bdabe07 100644
--- a/gcc/params.def
+++ b/gcc/params.def
@@ -1020,6 +1020,20 @@ DEFPARAM (PARAM_MAX_SLSR_CANDIDATE_SCAN,
 	  strength reduction,
 	  50, 1, 99)
 
+/* Maximum number of instructions to duplicate when shortcutting a switch.  */
+DEFPARAM (PARAM_MAX_SWITCH_INSNS,
+	  max-switch-insns,
+	  Maximum number of instructions to duplicate when 
+	  shortcutting a switch statement,
+	  100, 1, 99)
+
+/* Maximum number of paths to duplicate when shortcutting a switch.  */
+DEFPARAM (PARAM_MAX_SWITCH_PATHS,
+	  max-switch-paths,
+	  Maximum number of new paths to create when
+	   shortcutting a switch statement,
+	  50, 1, 99)
+
 /*
 Local variables:
 mode:c
diff --git a/gcc/passes.c b/gcc/passes.c
index fd67ee6..0fb826c 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -1416,6 +1416,7 @@ init_optimization_passes (void)
   NEXT_PASS (pass_call_cdce);
   NEXT_PASS (pass_cselim);
   NEXT_PASS (pass_tree_ifcombine);
+  NEXT_PASS (pass_switch_shortcut);
   NEXT_PASS (pass_phiopt);
   NEXT_PASS (pass_tail_recursion);
   NEXT_PASS (pass_ch);
diff --git a/gcc/timevar.def b/gcc

RE: [patch][mips] split mips_reorg in pre- and post-dbr_schedule parts

[Steve Ellcey]

Steven,

This patch has broken the GCC build for my mips-mti-linux-gnu and mips-mti-elf 
builds.  The GCC build dies
when trying to configure libgcc.  Do you have any idea what might be going on?

Steve Ellcey
sell...@imgtec.com


checking for mips-mti-linux-gnu-gcc... 
/local/home/sellcey/nightly2/obj-mips-mti-linux-gnu/gcc/initial/./gcc/xgcc 
-B/local/home/sellcey/nightly2/obj-mips-mti-linux-gnu/gcc/initial/./gcc/ 
-B/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/bin/
 
-B/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/lib/
 -isystem 
/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/include
 -isystem 
/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/sys-include
checking for suffix of object files... configure: error: in 
`/local/home/sellcey/nightly2/obj-mips-mti-linux-gnu/gcc/initial/mips-mti-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1

From the libgcc/config.log file:

configure:3376: 
/local/home/sellcey/nightly2/obj-mips-mti-linux-gnu/gcc/initial/./gcc/xgcc 
-B/local/home/sellcey/nightly2/obj-mips-mti-linux-gnu/gcc/initial/./gcc/ 
-B/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/bin/
 
-B/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/lib/
 -isystem 
/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/include
 -isystem 
/local/home/sellcey/nightly2/install-mips-mti-linux-gnu/mips-mti-linux-gnu/sys-include
-o conftest -g -O2 -minterlink-mips16   conftest.c  5
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: in update_ssa, at tree-into-ssa.c:3141
 }
 ^
0x95d7e0 update_ssa(unsigned int)
/local/home/sellcey/nightly2/src/gcc/gcc/tree-into-ssa.c:3141
0x8433fa execute_function_todo
/local/home/sellcey/nightly2/src/gcc/gcc/passes.c:1942
0x8455bd execute_todo
/local/home/sellcey/nightly2/src/gcc/gcc/passes.c:2002
Please submit a full bug report,with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.

Re: [patch][mips] split mips_reorg in pre- and post-dbr_schedule parts

[Steve Ellcey]

On Tue, 2013-05-07 at 18:39 +0200, Steven Bosscher wrote:
 On Tue, May 7, 2013 at 5:56 PM, Steve Ellcey wrote:
 
  Steven,
 
  This patch has broken the GCC build for my mips-mti-linux-gnu and 
  mips-mti-elf builds.  The GCC build dies
  when trying to configure libgcc.  Do you have any idea what might be going 
  on?
 
 Hello,
 
 Are you sure this is caused by my patch? It doesn't change anything
 for targets other than VR4130.
 
 Ciao!
 Steven

Yes, I did two builds, one with the git version just before this checkin
and one with the checkin.  This is the patch I am refering to, it
doesn't seem VR4130 specific.

Steve Ellcey
sell...@imgtec.com

2013-05-06  Steven Bosscher  ste...@gcc.gnu.org


* config/mips/mips.c: Include tree-pass.h.
(mips_reorg): Split in pre- and post-dbr_schedule parts.
(mips_machine_reorg2): Move mips_reorg post-dbr_schedule parts here.
(pass_mips_machine_reorg2): New machine specific pass.
(insert_pass_mips_machine_reorg2): New pass plugin definition.
(mips_option_override): Register the new pass.
* rtl.h (cleanup_barriers): Remove prototype.
(dbr_schedule): Likewise.
* jump.c (cleanup_barriers): Make static.
* reorg.c (dbr_schedule): Likewise.

Re: [patch][mips] split mips_reorg in pre- and post-dbr_schedule parts

[Steve Ellcey]

On Tue, 2013-05-07 at 19:16 +0200, Steven Bosscher wrote:

 On Tue, May 7, 2013 at 7:13 PM, Graham Stott wrote:
  Steven,
 
  The new execute mips_machine_reorrg2 part of the patch  doesn't have a 
  return value!
 
 Right, brilliant...  Thanks for spotting that.
 
 Steve, can you try this, please?
 
 
 Index: config/mips/mips.c
 ===
 --- config/mips/mips.c  (revision 198640)
 +++ config/mips/mips.c  (working copy)
 @@ -16388,6 +16388,7 @@ mips_machine_reorg2 (void)
 optimizations, but this should be an extremely rare case anyhow.  */
  mips_reorg_process_insns ();
mips16_split_long_branches ();
 +  return 0;
  }
 
  struct rtl_opt_pass pass_mips_machine_reorg2 =

Yes, this fixed my build.

Steve Ellcey
sell...@imgtec.com

Re: [patch, mips] Allow users to avoid promoting prototypes.

[Steve Ellcey]

On Thu, 2013-05-02 at 23:26 +0100, Richard Sandiford wrote:

 
  2013-05-02  Steve Ellcey  sell...@imgtec.com
 
  * config/mips/mips.c (mips_promote_prototypes) :New.
  (TARGET_PROMOTE_PROTOTYPES): Change to use mips_promote_prototypes.
  * config/mips/mips.opt (mpromote-prototypes): New.
 
 It'd need an invoke.texi change too.
 
 The ABI thing is a problem though.  Unlike the recent -mimadd option,
 this isn't something a user could reasonably turn on and off for
 individual files to see what happens.  They'd need to rebuild all
 their libraries with it.  And as written, the patch provides no way
 to compile gcc's own libraries that way, so they'd need to patch the
 gcc sources locally.

I wasn't looking at providing an extra set of libraries, my assumption
was that the libraries would be compiled with the default setting of
promoting prototypes they way they are now and that these would still
work with objects that were compiled with -mno-promote-prototypes.

 If you want to change the TARGET_PROMOTE_PROTOTYPES part of the
 ABI for mips*-mti-elf then that would be OK with me.  It would
 be better done without a command-line option.

I don't think I want to change the ABI for mips*-mti-elf at this point.

 I'm less keen on adding -mpromote-prototypes to mips*-mti-elf,
 both because of the large number of variations there already,
 and because continuing to have -mno-promote-prototypes multilibs
 would give the impression that the change isn't much of a win.

I definitely don't want to create another set of multilibs.
 
 Ideally we'd also have a .gnu_attribute to record which promotion
 rules are being used, so that the linker can pick up incompatibilities.
 
 Sorry to be a pain...
 
 Thanks,
 Richard

That's alright, I will drop this idea for now and perhaps look at
Richard Biener's idea (optimizing out the promotion on local calls)
later.

Steve Ellcey
sell...@imgtec.com

Re: [patch, mips] Fix for PR target/56942

[Steve Ellcey]

On Tue, 2013-04-30 at 15:05 +0100, Richard Sandiford wrote:
 Richard Sandiford rdsandif...@googlemail.com writes:
  Steven Bosscher stevenb@gmail.com writes:
  I dont like this at all.  At the very least, if we go this way,
  then all places where next_active_insn is used should be updated.
  Otherwise this is just confusion proliferation.
 
  You mean all places where next_active_insn is used to get the jump table?
  That would be fine with me, but as author of the original change,
  I'm going to ask you to do that if you feel strongly about it :-)
  Otherwise Steve's patch seems fine to me.
 
  Before my patch most
  ports used the active variants and I specifically did non fix the
  real variants. It is marked fixme for a reason: The JUMP_TABLE_DATA
  should always follow immediately after the label. Copying the fixme is
  a step in the wrong direction. Please do not commit this patch!
 
  But you didn't respond to my main point.  It always used to be the
  case that all active insns were also real.  I.e. real was a
  _more_ restrictive condition than active.
 
 Gah, I really wish proof reads before hitting send were as effective
 as those after.  Obviously that should read: active was a _more_
 restrictive condition than real.
 
 Richard

Steven,

Do you have any comment on Richard's question?  I am basically stuck
between the two of you with no way to fix my problem at this point
unless you allow the generic fix or Richard allows the MIPS specific
fix.

Steve Ellcey
sell...@imgtec.com

[patch, mips] Allow users to avoid promoting prototypes.

[Steve Ellcey]

MIPS architectures set TARGET_PROMOTE_PROTOTYPES to true.  I would like
to have an option to set this to false in order to avoid extra masking
when passing char or short types.  I don't think we can change this by
default since it would affect the ABI, but I would like to allow users
the option of turning if off if desired.

Tested on mips-mti-elf.  OK for checkin?

Steve Ellcey
sell...@imgtec.com


2013-05-02  Steve Ellcey  sell...@imgtec.com

* config/mips/mips.c (mips_promote_prototypes) :New.
(TARGET_PROMOTE_PROTOTYPES): Change to use mips_promote_prototypes.
* config/mips/mips.opt (mpromote-prototypes): New.


diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 7545b60..072a68b 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -5721,6 +5721,15 @@ mips_return_in_memory (const_tree type, const_tree 
fndecl ATTRIBUTE_UNUSED)
  ? TYPE_MODE (type) == BLKmode
  : !IN_RANGE (int_size_in_bytes (type), 0, 2 * UNITS_PER_WORD));
 }
+
+/* Implement TARGET_PROMOTE_PROTOTYPES.  It is true by default but can
+   be turned off with -mno-promote-prototypes.  */
+
+static bool
+mips_promote_prototypes (const_tree t ATTRIBUTE_UNUSED)
+{
+  return (mips_do_promote_prototypes != 0);
+}
 
 /* Implement TARGET_SETUP_INCOMING_VARARGS.  */
 
@@ -18708,7 +18717,7 @@ mips_expand_vec_minmax (rtx target, rtx op0, rtx op1,
 #undef  TARGET_PROMOTE_FUNCTION_MODE
 #define TARGET_PROMOTE_FUNCTION_MODE 
default_promote_function_mode_always_promote
 #undef TARGET_PROMOTE_PROTOTYPES
-#define TARGET_PROMOTE_PROTOTYPES hook_bool_const_tree_true
+#define TARGET_PROMOTE_PROTOTYPES mips_promote_prototypes
 
 #undef TARGET_FUNCTION_VALUE
 #define TARGET_FUNCTION_VALUE mips_function_value
diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index e11710d..1881d9d 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -305,6 +305,10 @@ mpaired-single
 Target Report Mask(PAIRED_SINGLE_FLOAT)
 Use paired-single floating-point instructions
 
+mpromote-prototypes
+Target Report Var(mips_do_promote_prototypes) Init(1)
+Promote integral arguments smaller then an int to int.
+
 mr10k-cache-barrier=
 Target Joined RejectNegative Enum(mips_r10k_cache_barrier_setting) 
Var(mips_r10k_cache_barrier) Init(R10K_CACHE_BARRIER_NONE)
 -mr10k-cache-barrier=SETTING   Specify when r10k cache barriers should be 
inserted

Re: [patch, mips] Fix for PR target/56942

[Steve Ellcey]

On Sat, 2013-04-27 at 08:56 +0100, Richard Sandiford wrote:

  But using next_real_insn was at least as correct (IMO, more correct)
  as next_active_insn before r197266.  It seems counterintuitive that
  something can be active but not real.
  
  Richard
 
  So should we put the active_insn_p hack/FIXME into real_next_insn?  That
  doesn't seem like much of a win but it would probably fix the problem.
 
 Yeah, I think so.  If = mean accepts more than, then there used
 to be a nice total order:
 
  next_insn
   = next_nonnote_insn
   = next_real_insn
   = next_active_insn
 
 I think we should keep that if possible, even during the transition period.
 
 Thanks,
 Richard

OK, here is patch to next_real_insn to keep the ordering property intact
and fix the bug.  OK for checkin?

Steve Ellcey
sell...@imgtec.com



2013-04-29  Andrew Bennett andrew.benn...@imgtec.com
Steve Ellcey  sell...@imgtec.com

PR target/56942
* emit-rtl.c (next_real_insn): Accept jump table data
as 'real' (like next_active_insn does).


diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 538b1ec..9de3f1e 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -3248,7 +3248,8 @@ next_real_insn (rtx insn)
   while (insn)
 {
   insn = NEXT_INSN (insn);
-  if (insn == 0 || INSN_P (insn))
+  if (insn == 0 || INSN_P (insn)
+ || JUMP_TABLE_DATA_P (insn)) /* FIXME */
break;
 }
 

Re: [patch, mips] Fix for PR target/56942

[Steve Ellcey]

On Wed, 2013-04-24 at 07:45 +0100, Richard Sandiford wrote:
 Steve Ellcey  sell...@imgtec.com writes:
  2013-04-19  Andrew Bennett andrew.benn...@imgtec.com
  Steve Ellcey  sell...@imgtec.com
 
  PR target/56942
  * config/mips/mips.md (casesi_internal_mips16_mode): Use
  next_active_insn instead of next_real_insn.
 
 Hmm, I don't really like this.  Steven said from ARM in
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809:
 
 ---
 Target bug, this is wrong:
 
   rtx diff_vec = PATTERN (next_real_insn (operands[2]));
 
 A jump_table_data is not a real insn.  Before my patch this worked
 by accident because the jump table would hide in a JUMP_INSN and 
 next_real_insn returned any JUMP_P insn.
 
 Use next_active_insn instead.
 ---
 
 But using next_real_insn was at least as correct (IMO, more correct)
 as next_active_insn before r197266.  It seems counterintuitive that
 something can be active but not real.
 
 Richard

So should we put the active_insn_p hack/FIXME into real_next_insn?  That
doesn't seem like much of a win but it would probably fix the problem.

Steve Ellcey
sell...@imgtec.com



From emit-rtl.c:

/* Find the next insn after INSN that really does something.  This routine
   does not look inside SEQUENCEs.  After reload this also skips over
   standalone USE and CLOBBER insn.  */

int
active_insn_p (const_rtx insn)
{
  return (CALL_P (insn) || JUMP_P (insn)
  || JUMP_TABLE_DATA_P (insn) /* FIXME */
  || (NONJUMP_INSN_P (insn)
   (! reload_completed
  || (GET_CODE (PATTERN (insn)) != USE
   GET_CODE (PATTERN (insn)) != CLOBBER;
}

[patch, mips] Fix for PR target/56942

[Steve Ellcey]

Andrew Bennett found this fix to my MIPS build problem (PR target/56942).
He does not have write access so I am submitting it for checkin, is this
a simple enough fix for an 'obvious' checkin?  I did a build and regression
test to verify the fix.

Steve Ellcey
sell...@imgtec.com



2013-04-19  Andrew Bennett andrew.benn...@imgtec.com
Steve Ellcey  sell...@imgtec.com

PR target/56942
* config/mips/mips.md (casesi_internal_mips16_mode): Use
next_active_insn instead of next_real_insn.


diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 2f62910..caf4614 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -6019,7 +6019,7 @@
(clobber (reg:SI MIPS16_T_REGNUM))]
   TARGET_MIPS16_SHORT_JUMP_TABLES
 {
-  rtx diff_vec = PATTERN (next_real_insn (operands[2]));
+  rtx diff_vec = PATTERN (next_active_insn (operands[2]));
 
   gcc_assert (GET_CODE (diff_vec) == ADDR_DIFF_VEC);
   

Re: [patch, mips] Patch to control the use of integer madd/msub instructions

[Steve Ellcey]

On Sat, 2013-03-23 at 14:50 +, Richard Sandiford wrote:

 This is similar in spirit to -mbranch-likely.  It'd be good for consistency
 if they were defined in a similar style.  I think that means removing
 !TARGET_MIPS16 from ISA_HAS_MADD_MSUB and instead having:
 
 #define GENERATE_MADD_MSUB  (TARGET_IMADD  !TARGET_MIPS16)
 
 There would also be:
 
 #define PTF_AVOID_IMADD 0x2
 
 which should be included in the 74k description, and a block similar to
 the MASK_BRANCHLIKELY one in mips_option_override.  There needs to be
 documentation in invoke.texi.

I can do it this way if you want, I was using -mllsc as my template for
how to implement this.  Do you think the -mllsc flag should be
implemented in the same way as -mbranch-likely?

 But -- sorry for the soapbox speech -- it would be better to retune
 so that new options aren't needed.  I'm assuming you're testing against
 the same microarchitecture that the original 74k authors were.  If so,
 it seems like -mimadd is just an option for choosing between two bad
 implementations.  One uses MADD and MSUB unconditionally (contrary to
 the experience of the original authors) and the other never uses it
 at all (contrary to your experience).
 
 That's not enough reason to reject the patch, just saying :-)

I agree that the 74k should only be using the integer madd/msub
instruction where it makes sense but I think having a flag to allow the
user to override it is still a good thing because the compiler won't
always be right.  Actually, one of my reasons for adding this flag is to
make it easier for me to do 74k runs with and without madd/msub and see
where we are using (but shouldn't) and hopefully improve the current
implementation.

Steve Ellcey
sell...@mips.com

Re: [patch, mips] Patch to control the use of integer madd/msub instructions

[Steve Ellcey]

On Mon, 2013-03-25 at 16:45 +, Richard Sandiford wrote:

 -mllsc is a little different in that it can be used even when the
 ISA doesn't support it (thanks to kernel emulation).  -mimadd isn't
 like that though: we only want to use MADD/MSUB if the ISA has it.
 So I think it makes sense to leave -mllsc as it is but do -mimadd
 in the same way as -mbranch-likely.
 
 Thanks,
 Richard

OK, Here is a patch that implements -mimadd in the same manner as
-mbranch-likely.

Steve Ellcey
sell...@imgtec.com


2013-03-25  Steve Ellcey  sell...@mips.com

* config/mips/mmips-cpus.def (74kc, 74kf2_1, 74kf, 74kf, 74kf1_1,
74kfx, 74kx, 74kf3_2): Add PTF_AVOID_IMADD.
* config/mips/mips.c (mips_option_override): Set IMADD default.
* config/mips/mips.h (PTF_AVOID_IMADD): New.
(ISA_HAS_MADD_MSUB): Remove MIPS16 check.
(GENERATE_MADD_MSUB): Remove TUNE_74K check, add MIPS16 check.
* config/mips/mips.md (mimadd): New flag for integer madd/msub.

diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-cpus.def
index 93c305a..c920c73 100644
--- a/gcc/config/mips/mips-cpus.def
+++ b/gcc/config/mips/mips-cpus.def
@@ -119,13 +119,13 @@ MIPS_CPU (34kfx, PROCESSOR_24KF1_1, 33, 0)
 MIPS_CPU (34kx, PROCESSOR_24KF1_1, 33, 0)
 MIPS_CPU (34kn, PROCESSOR_24KC, 33, 0)  /* 34K with MT but no DSP.  */
 
-MIPS_CPU (74kc, PROCESSOR_74KC, 33, 0) /* 74K with DSPr2.  */
-MIPS_CPU (74kf2_1, PROCESSOR_74KF2_1, 33, 0)
-MIPS_CPU (74kf, PROCESSOR_74KF2_1, 33, 0)
-MIPS_CPU (74kf1_1, PROCESSOR_74KF1_1, 33, 0)
-MIPS_CPU (74kfx, PROCESSOR_74KF1_1, 33, 0)
-MIPS_CPU (74kx, PROCESSOR_74KF1_1, 33, 0)
-MIPS_CPU (74kf3_2, PROCESSOR_74KF3_2, 33, 0)
+MIPS_CPU (74kc, PROCESSOR_74KC, 33, PTF_AVOID_IMADD) /* 74K with DSPr2.  */
+MIPS_CPU (74kf2_1, PROCESSOR_74KF2_1, 33, PTF_AVOID_IMADD)
+MIPS_CPU (74kf, PROCESSOR_74KF2_1, 33, PTF_AVOID_IMADD)
+MIPS_CPU (74kf1_1, PROCESSOR_74KF1_1, 33, PTF_AVOID_IMADD)
+MIPS_CPU (74kfx, PROCESSOR_74KF1_1, 33, PTF_AVOID_IMADD)
+MIPS_CPU (74kx, PROCESSOR_74KF1_1, 33, PTF_AVOID_IMADD)
+MIPS_CPU (74kf3_2, PROCESSOR_74KF3_2, 33, PTF_AVOID_IMADD)
 
 MIPS_CPU (1004kc, PROCESSOR_24KC, 33, 0) /* 1004K with MT/DSP.  */
 MIPS_CPU (1004kf2_1, PROCESSOR_24KF2_1, 33, 0)
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 252e828..0aaf4c6 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -16607,6 +16607,21 @@ mips_option_override (void)
 warning (0, the %qs architecture does not support branch-likely
  instructions, mips_arch_info-name);
 
+  /* If the user hasn't specified -mimadd or -mno-imadd set
+ MASK_IMADD based on the target architecture and tuning
+ flags.  */
+  if ((target_flags_explicit  MASK_IMADD) == 0)
+{
+  if (ISA_HAS_MADD_MSUB 
+  (mips_tune_info-tune_flags  PTF_AVOID_IMADD) == 0)
+   target_flags |= MASK_IMADD;
+  else
+   target_flags = ~MASK_IMADD;
+}
+  else if (TARGET_IMADD  !ISA_HAS_MADD_MSUB)
+warning (0, the %qs architecture does not support madd or msub
+ instructions, mips_arch_info-name);
+
   /* The effect of -mabicalls isn't defined for the EABI.  */
   if (mips_abi == ABI_EABI  TARGET_ABICALLS)
 {
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 0acce14..534ea26 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -42,13 +42,17 @@ extern int target_flags_explicit;
 #define ABI_EABI 3
 #define ABI_O64  4
 
-/* Masks that affect tuning.
-
-   PTF_AVOID_BRANCHLIKELY
-   Set if it is usually not profitable to use branch-likely instructions
-   for this target, typically because the branches are always predicted
-   taken and so incur a large overhead when not taken.  */
-#define PTF_AVOID_BRANCHLIKELY 0x1
+/* Masks that affect tuning.  */
+
+/* Set PTF_AVOID_BRANCHLIKELY if is usually not profitable to use
+   branch-likely instructions for this target, typically because
+   the branches are always predicted taken and so incur a large
+   overhead when not taken.  */
+#define PTF_AVOID_BRANCHLIKELY 0x1
+/* Set PTF_AVOID_IMADD if it is usually not profitable to use the
+   integer madd or msub instructions because of the overhead of
+   getting the result out of the HI/LO registers.  */
+#define PTF_AVOID_IMADD0x2
 
 /* Information about one recognized processor.  Defined here for the
benefit of TARGET_CPU_CPP_BUILTINS.  */
@@ -868,14 +872,13 @@ struct mips_cpu_info {
  !TARGET_MIPS16)
 
 /* ISA has integer multiply-accumulate instructions, madd and msub.  */
-#define ISA_HAS_MADD_MSUB  ((ISA_MIPS32\
- || ISA_MIPS32R2   \
- || ISA_MIPS64 \
- || ISA_MIPS64R2)  \
- !TARGET_MIPS16)
+#define ISA_HAS_MADD_MSUB  (ISA_MIPS32

[patch, mips] Patch to control the use of integer madd/msub instructions

[Steve Ellcey]

While testing GCC on a 74k MIPS chip I noticed that by default the -mtune=74k*
flags cause GCC to not use the integer madd/msub instructions.  According to
the checkin comments these were found to cause a performance hit over using
individual mult and add/sub instructions.  I think there are some programs
though where using madd/msub would be a win on the 74k and I would like to
have a flag to allow users to override the default behaviour (either turning
it on for 74k or turning it off for other achitectures).  This patch allows
-mimadd or -mno-imadd to override the default behaviour but does not change
that default behaviour.

OK for checkin?

Steve Ellcey
sell...@imgtec.com


2013-03-22  Steve Ellcey  sell...@mips.com

* config/mips/mips.md (mimadd): New flag for integer madd/msub.
* config/mips/mips.h (GENERATE_MADD_MSUB): Check -mimadd flag.


diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 0acce14..62a7701 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -875,7 +875,9 @@ struct mips_cpu_info {
  !TARGET_MIPS16)
 
 /* Integer multiply-accumulate instructions should be generated.  */
-#define GENERATE_MADD_MSUB  (ISA_HAS_MADD_MSUB  !TUNE_74K)
+#define GENERATE_MADD_MSUB (ISA_HAS_MADD_MSUB \
+ (target_flags_explicit  MASK_IMADD \
+   ? TARGET_IMADD : !TUNE_74K))
 
 /* ISA has floating-point madd and msub instructions 'd = a * b [+-] c'.  */
 #define ISA_HAS_FP_MADD4_MSUB4  ISA_HAS_FP4
diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index d8ef2e7..6b3024b 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -58,6 +58,10 @@ mmad
 Target Report Var(TARGET_MAD)
 Use PMC-style 'mad' instructions
 
+mimadd
+Target Report Mask(IMADD)
+Use integer madd/msub instructions
+
 march=
 Target RejectNegative Joined Var(mips_arch_option) ToLower 
Enum(mips_arch_opt_value)
 -march=ISA Generate code for the given ISA

[patch, testsuite] Obvious patch for gcc.dg/pr56396.c

[Steve Ellcey]

I am going to check in this testsuite patch as an obvious fix.  We should make
sure a platform supports PIC before compiling with the -fpic flag.

Steve Ellcey
sell...@imgtec.com


2013-03-01  Steve Ellcey  sell...@mips.com

* gcc.dg/pr56396.c: Require pic support.


diff --git a/gcc/testsuite/gcc.dg/pr56396.c b/gcc/testsuite/gcc.dg/pr56396.c
index d2ec8fa..160545b 100644
--- a/gcc/testsuite/gcc.dg/pr56396.c
+++ b/gcc/testsuite/gcc.dg/pr56396.c
@@ -1,5 +1,6 @@
 /* PR tree-optimization/56396 */
 /* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
 /* { dg-options -O2 -fpic -g } */
 
 struct S { char *s; int z; };

RE: PR target/52555: attribute optimize is overriding command line options

[Steve Ellcey]

Jakub and Aldy,

It looks like I am having another problem with this patch.  Jakubs earlier 
patch fixed things
for me when building my mips-mti-elf target but I just started building glibc 
in mips16 mode
with the latest compiler and I am running into this assert:

mktime.c:147:1: internal compiler error: in save_optabs_if_changed, at 
optabs.c:6221
 {
 ^
0x8198e5 save_optabs_if_changed(tree_node*)
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/optabs.c:6221
0x4b090b decl_attributes(tree_node**, tree_node*, int)
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/attribs.c:545
0x4cf728 start_function(c_declspecs*, c_declarator*, tree_node*)
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/c/c-decl.c:7727
0x557114 c_common_parse_file()
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/c-family/c-opts.c:1046

I looked at this_target_optabs and it appears to be a valid pointer but it is 
not pointing at
default_target_optabs addr and so I get the assert.  I am still trying to dig 
out more 
information and create a good test case.

Steve Ellcey
sell...@imgtec.com

RE: [PATCH] MIPS: MIPS32r2 FP MADD instruction set support

[Steve Ellcey]

From: Maciej W. Rozycki [ma...@codesourcery.com]

  Steve, would you therefore please do us a favour and check what the AVP
 for MIPS32r2 requires for support of the floating-point MADD instruction
 subset, or preferably, the whole COP1X instruction set?  Are these
 instructions only mandatory for a 64-bit FPU (CP1.FIR.F64 == 1), or do
 they have to be included in all FPU implementations

Maciej,

I checked with one of the AVP engineers and he said:

madd/msub/nmadd/nmsub.fmt instructions are required for all release 2 
implementations,
whether or not that implementation has a 64 bit fpu. They are also required for 
mips64
release 1 implementations.  The AVPs check for this.

Steve Ellcey

Re: PR target/52555: attribute optimize is overriding command line options

[Steve Ellcey]

On Fri, 2013-02-22 at 11:03 +0100, Jakub Jelinek wrote:

 The problem I believe is that Aldy has changed init_optabs and insn-opinit.c
 to use this_fn_optabs instead of this_target_optabs, but it is only set in
 invoke_set_current_function_hook.  During save_target_globals we want to
 init this_target_optabs, so we need to temporarily switch this_fn_optabs to
 make that happen.
 
 2013-02-22  Jakub Jelinek  ja...@redhat.com
 
   PR target/52555
   * target-globals.c (save_target_globals): For init_reg_sets and
   target_reinit remporarily set this_fn_optabs to this_target_optabs.
 

Jakub,

I built with this patch and ran the GCC testsuite (using the target
mips-mti-linux-gnu), it fixed the problem and caused no regressions for
me.

Steve Ellcey
sell...@imgtec.com

RE: PR target/52555: attribute optimize is overriding command line options

[Steve Ellcey]

On Mon, Feb 18, 2013 at 12:50:59PM -0600, Aldy Hernandez wrote:
 OK pending tests?

   PR target/52555
   * genopinit.c (raw_optab_handler): Use this_fn_optabs.
   (swap_optab_enable): Same.
   (init_all_optabs): Use argument instead of global.
   * tree.h (struct tree_optimization_option): New field
   target_optabs.
   * expr.h (init_all_optabs): Add argument to prototype.
   (TREE_OPTIMIZATION_OPTABS): New.
   (save_optabs_if_changed): Protoize.
   * optabs.h: Declare this_fn_optabs.
   * optabs.c (save_optabs_if_changed): New.
   Declare this_fn_optabs.
   (init_optabs): Add argument to init_all_optabs() call.
   * function.c (invoke_set_current_function_hook): Handle per
   function optabs.
   * function.h (struct function): New field optabs.
   * config/mips/mips.c (mips_set_mips16_mode): Handle when
   optimization_current_node has changed.
   * target-globals.h (save_target_globals_default_opts): Protoize.
   * target-globals.c (save_target_globals_default_opts): New.
 c/family
   PR target/52555
   * c-common.c (handle_optimize_attribute): Call
   save_optabs_if_changed.

Aldy,

Have you gotten any reports of problems with this patch?  It seems to be 
sending cc1 into an infinite
loop during the GCC testsuite for me.  I am testing the mips-mti-linux-gnu 
target and tests like
gcc.target/mips/call-saved-1.c are causing cc1 to suck up all my memory and 
swap space before the
test times out.

I will keep digging and see if I can figure out what is going on but I wanted 
to see if anyone else has
reported this problem.

Steve Ellcey
sell...@imgtec.com

[patch, libstdc++, testsuite] Fix simulator timouts.

[Steve Ellcey]

Here is a patch for the last of the C++ library tests that fail for me when
run under the gnu simulator due to memory usage.

I am using the same define mechanism to shrink them when run on a simulator
as other tests are already using.

Tested on mips-mti-elf target with no regressions.

OK to checkin?

Steve Ellcey
sell...@mips.com


2013-01-14  Steve Ellcey  sell...@mips.com

* 
testsuite/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc:
Shrink memory usage under simulator.
* testsuite/libstdc++-v3/testsuite/26_numerics/valarray/28277.cc: Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-1.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-2.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_stringbuf/overflow/wchar_t/1.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_stringbuf/setbuf/wchar_t/4.cc:
Ditto.


diff --git a/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc 
b/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc
index 1e9d01a..7806fb2 100644
--- a/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc
+++ b/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc
@@ -1,6 +1,12 @@
 // Test vector: performance difference 25% (0.444s vs 0.539s)
 // Advice: set tmp as 1
 
+// { dg-options -DITERATIONS=20 { target simulator } }
+
+#ifndef ITERATIONS
+#define ITERATIONS 2000
+#endif
+
 #include vector
 
 using std::vector;
@@ -9,7 +15,7 @@ int main()
 {
   vector int tmp;
 
-  for (int j=0; j2000; j++)
+  for (int j=0; jITERATIONS; j++)
 // Insert more than default item
 for (int i=0; i1; i++) {
   tmp.push_back(i);
diff --git a/libstdc++-v3/testsuite/26_numerics/valarray/28277.cc 
b/libstdc++-v3/testsuite/26_numerics/valarray/28277.cc
index 7e619c0..d14a6f1 100644
--- a/libstdc++-v3/testsuite/26_numerics/valarray/28277.cc
+++ b/libstdc++-v3/testsuite/26_numerics/valarray/28277.cc
@@ -17,6 +17,12 @@
 // with this library; see the file COPYING3.  If not see
 // http://www.gnu.org/licenses/.
 
+// { dg-options -DMAX_SIZE=5000 { target simulator } }
+
+#ifndef MAX_SIZE
+#define MAX_SIZE 500
+#endif
+
 #include valarray
 #include testsuite_hooks.h
 
@@ -25,7 +31,7 @@ void test01()
 {
   bool test __attribute__((unused)) = true;
 
-  const std::valarrayint v1(1, 500);
+  const std::valarrayint v1(1, MAX_SIZE);
 
   const std::valarrayint v2 = v1.shift(1);
   VERIFY( v2.size() == v1.size() );
diff --git 
a/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc
index 2e27c80..1b94684 100644
--- 
a/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc
+++ 
b/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc
@@ -19,6 +19,12 @@
 
 // 27.6.1.2.3 basic_istream::operator
 
+// { dg-options -DMAX_SIZE=466 { target simulator } }
+
+#ifndef MAX_SIZE
+#define MAX_SIZE 666
+#endif
+
 #include istream
 #include string
 #include fstream
@@ -70,7 +76,7 @@ void test01()
   const char filename[] = inserters_extractors-4.txt;
 
   const unsigned nchunks = 10;
-  const wstring data = prepare(666, nchunks);
+  const wstring data = prepare(MAX_SIZE, nchunks);
 
   wofstream ofstrm;
   ofstrm.open(filename);
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc
index 39fb595..cd97df5 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc
@@ -17,6 +17,12 @@
 
 // 27.6.1.3 unformatted input functions
 
+// { dg-options -DMAX_LENGTH=7 { target simulator } }
+
+#ifndef MAX_LENGTH
+#define MAX_LENGTH 777
+#endif
+
 #include istream
 #include string
 #include fstream
@@ -68,7 +74,7 @@ void test01()
 
   const wchar_t delim = L'|';
   const unsigned nchunks = 10;
-  const wstring data = prepare(777, nchunks, delim);
+  const wstring data = prepare(MAX_LENGTH, nchunks, delim);
 
   wofstream ofstrm;
   ofstrm.open(filename);
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc
index 8a24210..519c038 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc
@@ -17,6 +17,12 @@
 
 // 27.6.1.3 unformatted input functions
 
+// { dg-options -DMAX_SIZE=355

Re: [patch, mips, stabs] Do any MIPS targets use stabs?

[Steve Ellcey]

On Mon, 2013-01-07 at 12:54 -0800, Steve Ellcey wrote:
 On Mon, 2013-01-07 at 20:38 +, Richard Sandiford wrote:
 
  
  Ah, sorry, this reminded me of a patch I'd written a year ago and never
  got around to sanity-checking.  Does it fix the problem for you?
  
  Richard
 
 It fixes my small test case, I will try it on the full testsuite
 overnight.
 
 Steve

The full testsuite worked fine too, so I think this should be checked
in.  Given this fix I will probably leave the stab support alone for
now, though I would have no objection if someone wanted to remove it for
MIPS.

Steve Ellcey
sell...@mips.com

[patch, mips, stabs] Do any MIPS targets use stabs?

[Steve Ellcey]

While testing all the variations of my mips-mti-elf target I found that
a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
using a stabs debug flag (-gstabs3 for example) and -mips16.  While running
the GNU simulator I get:

mips-core: 1 byte read to unmapped address 0xe820 at 0x80020278
program stopped with signal 10 (User defined signal 1).
FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test

Since I don't actually care about STABS I was looking at undefining 
DBX_DEBUGGING_INFO in mips-mti-elf.h and mips-mti-linux.h which makes
the failures a moot point for me since I would no longer run the tests
with any -stabs flags.

But I was wondering, are there any MIPS targets that do use stabs?  If not
maybe we should just remove the define of DBX_DEBUGGING_INFO from mips.h
instead of undefing it just for my targets.  Opinions?

I saw the discussion about removing STABS completely from GCC, etc. but it
looks like there is still some users who want it on some targets.

Here is my default patch which just undef's it for the mti targets.

Steve Ellcey
sell...@mips.com



2013-01-07  Steve Ellcey  sell...@mips.com

* config/mips/mips-mti-elf.h: undef DBX_DEBUGGING_INFO.
* config/mips/mips-mti-linux.h: Ditto.


diff --git a/gcc/config/mips/mti-elf.h b/gcc/config/mips/mti-elf.h
index f6b38a5..f90b060 100644
--- a/gcc/config/mips/mti-elf.h
+++ b/gcc/config/mips/mti-elf.h
@@ -41,3 +41,6 @@ along with GCC; see the file COPYING3.  If not see
\
   /* Configuration-independent MIPS rules.  */ \
   BASE_DRIVER_SELF_SPECS
+
+
+#undef DBX_DEBUGGING_INFO
diff --git a/gcc/config/mips/mti-linux.h b/gcc/config/mips/mti-linux.h
index cda9bdc..c12138f 100644
--- a/gcc/config/mips/mti-linux.h
+++ b/gcc/config/mips/mti-linux.h
@@ -45,3 +45,5 @@ along with GCC; see the file COPYING3.  If not see
\
   /* Use the standard linux specs for everything else.  */ \
   LINUX64_DRIVER_SELF_SPECS
+
+#undef DBX_DEBUGGING_INFO

[patch, mips] Change -mad to -mmad to match documentation

[Steve Ellcey]

The MIPS documentation describes a -mmad (-mno-mad) flag, but it is incorrectly
implemented as -mad (-mno-ad) instead.  This patch changes the implementation
to match the documentation.  This means that users who are currently using the
-mad or -mno-ad flags would have to change.  If we want we could leave -mad and
-mno-ad as aliases for -mmad and -mno-ad but I don't think that is necessary.

If someone does think we should do allow -mad, please let me know.

OK to checkin?

Steve Ellcey
sell...@mips.com


2013-01-07  Steve Ellcey  sell...@mips.com

PR target/42661
* config/mips/mips.opt: Change mad to mmad to match documentation.


diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index dec028d..201d46f 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -55,7 +55,7 @@ mabicalls
 Target Report Mask(ABICALLS)
 Generate code that can be used in SVR4-style dynamic objects
 
-mad
+mmad
 Target Report Var(TARGET_MAD)
 Use PMC-style 'mad' instructions
 

Re: [patch, mips, stabs] Do any MIPS targets use stabs?

[Steve Ellcey]

On Mon, 2013-01-07 at 20:30 +, Richard Sandiford wrote:
 Steve Ellcey  sell...@mips.com writes:
  While testing all the variations of my mips-mti-elf target I found that
  a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
  using a stabs debug flag (-gstabs3 for example) and -mips16.  While running
  the GNU simulator I get:
 
  mips-core: 1 byte read to unmapped address 0xe820 at 0x80020278
  program stopped with signal 10 (User defined signal 1).
  FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test
 
 Do you know why selecting stabs causes an execution failure?
 That shouldn't happen regardless of whether the debug info itself is good.
 
 I don't mind removing stabs from all MIPS targets, but I'd like to
 understand why we get the execution failure first.
 
 Richard

No, I don't know why I get the execution failure.  I dug around a bit
but could not figure out what or where the problem was coming from.  I
assume the executable is accessing a bad address or an uninitialized bit
of memory somewhere but I could not figure out where.  The actual
executable code is the same with or without the debug information.  I
don't even know if this is a bug in GCC or in the GNU simulator.  My
inability to figure out where the problem was occurring is the main
reason I started wondering why I even cared about stabs.

Steve Ellcey
sell...@mips.com

Re: [patch, mips, stabs] Do any MIPS targets use stabs?

[Steve Ellcey]

On Mon, 2013-01-07 at 20:38 +, Richard Sandiford wrote:

 
 Ah, sorry, this reminded me of a patch I'd written a year ago and never
 got around to sanity-checking.  Does it fix the problem for you?
 
 Richard

It fixes my small test case, I will try it on the full testsuite
overnight.

Steve

Re: [patch] Performance patch for MIPS conditional move in expr.c

[Steve Ellcey]

On Thu, 2012-11-15 at 13:39 -0800, Andrew Pinski wrote:

  I was posting it for Steve's benefit really.  I was in the process of
  updating the patch to the trunk and trying it out there before doing a
  formal submission :).  As I found out the testcase needs to be changed
  to work with the new mips target test infrastructure.  I will post a
  revised patch with the removal of the internal bug number once I
  finish fixing the testcase itself.
 
 After fixing up the testcase I find xori still in the resulting code:
 gcc$ ./cc1 t.c -O1 -o - -DNOMIPS16= -quiet -mabi=n32  -march=mips64 |grep xor
   xori$2,$4,0x1
 
 But that is because combine produces:
 Trying 34 - 35:
 Failed to match this instruction:
 (set (reg:SI 194 [ D.1393 ])
 (if_then_else:SI (xor:SI (reg:SI 200 [ d ])
 (const_int 1 [0x1]))
 (reg:SI 6 $6 [ c ])
 (reg:SI 5 $5 [ b ])))
 
 But does not switch around the if_then_else as reg 200 has a non zero
 bits of just 1.  I will look into fix the rest of the problem later
 today.  So the above patch is a way forward but not the full fix.
 
 Thanks,
 Andrew Pinski

Andrew, are you still planning on submitting this patch?  I have been
running with your new *movGPR:mode_on_GPR2:mode_ne instruction
and that part at least works fine.  I would like to get at least that
much checked in for GCC 4.8.

Steve Ellcey
sell...@mips.com

Re: [Patch, PR 54128] ira.c change to fix mips bootstrap

[Steve Ellcey]

On Fri, 2012-12-21 at 08:46 +0100, Jakub Jelinek wrote:

 Given Alex' comments in the PR, the second hunk is definitely ok for trunk,
 the first one can be applied too (but you can skip it too if you want, it
 shouldn't make a difference).


Thanks, I checked in both chunks.

Steve Ellcey
sell...@mips.com

[patch, libstdc++ testsuite] Shrink more tests for simulator

[Steve Ellcey]

Here are four more C++ tests that fail for me when run under the GNU
simulator.  I would like to shrink them to use less memory in the same
way as the other tests that I modified earlier.

OK to checkin?

Steve Ellcey
sell...@mips.com


2012-12-14  Steve Ellcey  sell...@mips.com

* testsuite/21_strings/basic_string/append/wchar_t/3.cc: Shrink
memory usage under simulator.
* testsuite/21_strings/basic_string/cons/wchar_t/6.cc: Ditto.
* testsuite/21_strings/basic_string/inserters_extractors/wchar_t/10.cc:
Ditto.
* testsuite/21_strings/basic_string/inserters_extractors/wchar_t/11.cc:
Ditto.


diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/append/wchar_t/3.cc 
b/libstdc++-v3/testsuite/21_strings/basic_string/append/wchar_t/3.cc
index dca5dbd..d20b994 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/append/wchar_t/3.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/append/wchar_t/3.cc
@@ -19,6 +19,12 @@
 
 // 21.3.5 string modifiers
 
+// { dg-options -DITERATIONS=14 { target simulator } }
+
+#ifndef ITERATIONS
+#define ITERATIONS 18
+#endif
+
 #include string
 #include testsuite_hooks.h
 
@@ -37,7 +43,7 @@ test03()
 {
   wstring one(source);
   wstring two(source);
-  for (unsigned j = 0; j  18; ++j)
+  for (unsigned j = 0; j  ITERATIONS; ++j)
{
  VERIFY( one == two );
  one.append(one);
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/cons/wchar_t/6.cc 
b/libstdc++-v3/testsuite/21_strings/basic_string/cons/wchar_t/6.cc
index 82ed764..95acdd0 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/cons/wchar_t/6.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/cons/wchar_t/6.cc
@@ -19,6 +19,12 @@
 
 // 21.3.1 basic_string constructors.
 
+// { dg-options -DITERATIONS=11 { target simulator } }
+
+#ifndef ITERATIONS
+#define ITERATIONS 13
+#endif
+
 #include iterator
 #include sstream
 #include cstdlib
@@ -50,6 +56,6 @@ void test01(int iter)
 
 int main()
 {
-  test01(13);
+  test01(ITERATIONS);
   return 0;
 }
diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/10.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/10.cc
index 0883e13..a647c39 100644
--- 
a/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/10.cc
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/10.cc
@@ -17,6 +17,12 @@
 
 // 21.3.7.9 inserters and extractors
 
+// { dg-options -DMAX_SIZE=505 { target simulator } }
+
+#ifndef MAX_SIZE
+#define MAX_SIZE 777
+#endif
+
 #include istream
 #include string
 #include fstream
@@ -64,7 +70,7 @@ void test01()
 
   const wchar_t delim = L'|';
   const unsigned nchunks = 10;
-  const wstring data = prepare(777, nchunks, delim);
+  const wstring data = prepare(MAX_SIZE, nchunks, delim);
 
   wofstream ofstrm;
   ofstrm.open(filename);
diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/11.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/11.cc
index 2f174ca..a0a822f 100644
--- 
a/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/11.cc
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/11.cc
@@ -17,6 +17,12 @@
 
 // 21.3.7.9 inserters and extractors
 
+// { dg-options -DMAX_SIZE=466 { target simulator } }
+
+#ifndef MAX_SIZE
+#define MAX_SIZE 666
+#endif
+
 #include istream
 #include string
 #include fstream
@@ -63,7 +69,7 @@ void test01()
   const char filename[] = inserters_extractors-3.txt;
 
   const unsigned nchunks = 10;
-  const wstring data = prepare(666, nchunks);
+  const wstring data = prepare(MAX_SIZE, nchunks);
 
   wofstream ofstrm;
   ofstrm.open(filename);

[patch, testsuite, committed] Obvious fix for targets with no profiling

[Steve Ellcey]

I am going to check in this patch as the obvious fix for PR 55688.  I
tested it on mips-mti-elf.

Steve Ellcey
sell...@mips.com


2012-12-14  Steve Ellcey  sell...@mips.com

PR regression/55688
* g++.dg/other/pr55650.C: Add dg-require-profiling.


diff --git a/gcc/testsuite/g++.dg/other/pr55650.C 
b/gcc/testsuite/g++.dg/other/pr55650.C
index fc52b19..c565b06 100644
--- a/gcc/testsuite/g++.dg/other/pr55650.C
+++ b/gcc/testsuite/g++.dg/other/pr55650.C
@@ -1,5 +1,6 @@
 // PR gcov-profile/55650
 // { dg-do link }
+// { dg-require-profiling -fprofile-generate }
 // { dg-options -O2 -fprofile-generate }
 // { dg-additional-sources pr55650.cc }
 

Re: [patch, libstdc++ testsuite] Shrink tests for simulator

[Steve Ellcey]

On Thu, 2012-12-13 at 20:27 +0100, Paolo Carlini wrote:

 It's the same approach that we are following in many other places, right?

Yes, it is the same approach.

  OK to checkin?
 Yes, thanks.

Done.

Steve Ellcey
sell...@mips.com

Re: [patch, mips] Follow up to pr54061 patch, fix another abort.

[Steve Ellcey]

On Wed, 2012-12-12 at 08:21 +, Richard Sandiford wrote:

 I'm pretty sure we'll need more eventually though.  A quick inspection
 shows that we don't set mips_dbx_regno for DSP_ACC_REGS or ST_REGS.
 DSP_ACC_REGS in paticular seems likely to hit, although you need to
 test with an -mdsp option to get coverage.  It's even conceivable
 that we could end up with info for GOT_VERSION_REGNUM.
 
 I don't think we really gain much by trying to distinguish in mips_dbx_regno
 between INVALID_REGNUM (register isn't used at all by the compiler) and
 IGNORED_DWARF_REGNUM.  Especially since we don't distinguish between
 registers that have been disabled through -msoft-float, -mips3 and below
 (for ST_REGS other than $fcc0), -mno-dsp, etc.
 
 Richard

OK, you have convinced me.  Here is what I am testing, OK to checkin
once I have run it through the testsuite?

Steve Ellcey
sell...@mips.com


2012-12-12  Steve Ellcey  sell...@mips.com

* config/mips/mips.c (mips_option_override): Set
mips_dbx_regno entries to IGNORED_DWARF_REGNUM by default.


diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 820b228..7ac8bb7 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -16742,7 +16742,7 @@ mips_option_override (void)
 
   for (i = 0; i  FIRST_PSEUDO_REGISTER; i++)
 {
-  mips_dbx_regno[i] = INVALID_REGNUM;
+  mips_dbx_regno[i] = IGNORED_DWARF_REGNUM;
   if (GP_REG_P (i) || FP_REG_P (i) || ALL_COP_REG_P (i))
mips_dwarf_regno[i] = i;
   else
@@ -16757,9 +16757,6 @@ mips_option_override (void)
   for (i = FP_REG_FIRST; i = FP_REG_LAST; i++)
 mips_dbx_regno[i] = i + start;
 
-  for (i = ALL_COP_REG_FIRST; i = ALL_COP_REG_LAST; i++)
-mips_dbx_regno[i] = IGNORED_DWARF_REGNUM;
-
   /* Accumulator debug registers use big-endian ordering.  */
   mips_dbx_regno[HI_REGNUM] = MD_DBX_FIRST + 0;
   mips_dbx_regno[LO_REGNUM] = MD_DBX_FIRST + 1;

[patch, testsuite] Check for pic support on tests that use -fPIC

[Steve Ellcey]

I think this patch qualifies as obvious so I will check it in later today if
I don't get any objections.  These two tests use the -fPIC flag but do not
check for pic support.  Tested on mips-mti-elf.

Steve Ellcey
sell...@mips.com


2012-12-12  Steve Ellcey  sell...@mips.com

* gcc.dg/pr55150-2.c: Add pic support check.
* gcc.dg/lto/pr54709_0.c: Ditto.

diff --git a/gcc/testsuite/gcc.dg/lto/pr54709_0.c 
b/gcc/testsuite/gcc.dg/lto/pr54709_0.c
index 7e38bd4..f3db5dc 100644
--- a/gcc/testsuite/gcc.dg/lto/pr54709_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr54709_0.c
@@ -1,5 +1,6 @@
 /* { dg-lto-do link } */
 /* { dg-require-visibility hidden } */
+/* { dg-require-effective-target fpic } */
 /* { dg-extra-ld-options { -shared } } */
 /* { dg-lto-options { { -fPIC -fvisibility=hidden -flto } } } */
 
diff --git a/gcc/testsuite/gcc.dg/pr55150-2.c b/gcc/testsuite/gcc.dg/pr55150-2.c
index 48dbb53..1be769d 100644
--- a/gcc/testsuite/gcc.dg/pr55150-2.c
+++ b/gcc/testsuite/gcc.dg/pr55150-2.c
@@ -1,5 +1,6 @@
 /* PR middle-end/55150 */
 /* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
 /* { dg-options -Os -g -fPIC } */
 
 typedef unsigned char DES_cblock[8];

[patch, mips] Patch to allow madd, etc without 64 bit floating point

[Steve Ellcey]

The MIPS32 architecture supports madd, msub, nmadd, and nmsub instructions
as well as rsqrt and recip instructions even when it doesn't have a 64 bit
floating point unit.  This was not clear in the original MIPS32 architecture
document (MD00086) but was clarified in 2011 (version 3.0.2, March 21, 2011).
This patch updates the ISA_HAS_FP4 and ISA_HAS_NMADD4_NMSUB4 macros and the
recip_condition mode attribute to allow the use of these instructions for all
MIPS32 architectures (with or without FLOAT64).

Testing showed one new test failure (gcc.target/mips/rsqrt-4.c) which I 
updated to reflect that we can now generate and use a rsqrt.d instruction.

I put Chao-ying and Maciej's names on the patch since they did the
original changes in GCC but those changes were never checked in upstream.

OK to checkin?

Steve Ellcey
sell...@mips.com



In the spec MD00086, page 347 Revision History, 3.0.2, March 21, 2011, RECIP, R
SQRT instructions do not require 64-bit FPU.



2012-12-12  Steve Ellcey  sell...@mips.com
Chao-ying Fu  f...@mips.com
Maciej W. Rozycki  ma...@codesourcery.com

* config/mips/mips.h (ISA_HAS_FP4): Allow madd, etc. on all MIPS32R2.
(ISA_HAS_NMADD4_NMSUB4): Ditto.
* config/mips/mips.md (recip_condition): Allow recip and rsqrt on
all MIPS32R2.

diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 60b26cb..44874e9 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -858,7 +858,7 @@ struct mips_cpu_info {
FP madd and msub instructions, and the FP recip and recip sqrt
instructions.  */
 #define ISA_HAS_FP4((ISA_MIPS4 \
- || (ISA_MIPS32R2  TARGET_FLOAT64)   \
+ || ISA_MIPS32R2   \
  || ISA_MIPS64 \
  || ISA_MIPS64R2)  \
  !TARGET_MIPS16)
@@ -889,10 +889,7 @@ struct mips_cpu_info {
 /* ISA has floating-point nmadd and nmsub instructions
'd = -((a * b) [+-] c)'.  */
 #define ISA_HAS_NMADD4_NMSUB4(MODE)\
-   ((ISA_MIPS4 \
- || (ISA_MIPS32R2  (MODE) == V2SFmode) \
- || ISA_MIPS64 \
- || ISA_MIPS64R2)  \
+(ISA_HAS_FP4   \
  (!TARGET_MIPS5400 || TARGET_MAD)\
  !TARGET_MIPS16)
 
diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index a3aa922..796597e 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -858,12 +858,10 @@
   [(SF !ISA_MIPS1) (DF !ISA_MIPS1) (V2SF TARGET_SB1)])
 
 ;; This attribute gives the conditions under which RECIP.fmt and RSQRT.fmt
-;; instructions can be used.  The MIPS32 and MIPS64 ISAs say that RECIP.D
-;; and RSQRT.D are unpredictable when doubles are stored in pairs of FPRs,
-;; so for safety's sake, we apply this restriction to all targets.
+;; instructions can be used.
 (define_mode_attr recip_condition
   [(SF ISA_HAS_FP4)
-   (DF ISA_HAS_FP4  TARGET_FLOAT64)
+   (DF ISA_HAS_FP4)
(V2SF TARGET_SB1)])
 
 ;; This code iterator allows signed and unsigned widening multiplications

= Test change ===

2012-12-12  Steve Ellcey  sell...@mips.com

* gcc.target/mips/rsqrt-4.c: Update to show use of sqrt.d.


diff --git a/gcc/testsuite/gcc.target/mips/rsqrt-4.c 
b/gcc/testsuite/gcc.target/mips/rsqrt-4.c
index 6b6577e..471dd28 100644
--- a/gcc/testsuite/gcc.target/mips/rsqrt-4.c
+++ b/gcc/testsuite/gcc.target/mips/rsqrt-4.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options -ffast-math -mips64 -mhard-float -mgp32 } */
 /* { dg-skip-if code quality test { *-*-* } { -O0 } {  } } */
-/* { dg-final { scan-assembler-not \trsqrt.d\t } } */
+/* { dg-final { scan-assembler-times \trsqrt.d\t 2 } } */
 /* { dg-final { scan-assembler-times \trsqrt.s\t 2 } } */
 
 extern double sqrt(double);

Re: [patch, mips] Patch to allow madd, etc without 64 bit floating point

[Steve Ellcey]

On Wed, 2012-12-12 at 22:21 +, Maciej W. Rozycki wrote:

  Given that, how about we coordinate these submissions -- I'll dig out the 
 most recent version of the madd change and push it through testing before 
 I post it and you do the reciprocals?
 
   Maciej

That sounds good to me.

Steve Ellcey
sell...@mips.com

[patch, mips] Follow up to pr54061 patch, fix another abort.

[Steve Ellcey]

While building libgcc in mips16 mode I found another instance of
dbx_reg_number aborting that the patch to pr54061 did not fix.
This code:

extern void __chk_fail (void) __attribute__ ((__noreturn__));
__strncpy_chk (s1, s2, n, s1len)
{
  char c;
  char *s = s1;
  if (__builtin_expect (s1len  n, 0))
__chk_fail ();
  while (c != '\0');
  return s;
}

aborts when compiled with -O2 -g -fpic -mips16.  The following patch
fixes it.  OK to checkin?

Steve Ellcey
sell...@mips.com


2012-12-11  Steve Ellcey  sell...@mips.com

* config/mips/mips.c (mips_option_override): Set
mips_dbx_regno[CPRESTORE_SLOT_REGNUM] to IGNORED_DWARF_REGNUM.


diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 820b228..8113e5d 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -16760,6 +16760,8 @@ mips_option_override (void)
   for (i = ALL_COP_REG_FIRST; i = ALL_COP_REG_LAST; i++)
 mips_dbx_regno[i] = IGNORED_DWARF_REGNUM;
 
+  mips_dbx_regno[CPRESTORE_SLOT_REGNUM] = IGNORED_DWARF_REGNUM;
+
   /* Accumulator debug registers use big-endian ordering.  */
   mips_dbx_regno[HI_REGNUM] = MD_DBX_FIRST + 0;
   mips_dbx_regno[LO_REGNUM] = MD_DBX_FIRST + 1;

Re: [patch, mips] Follow up to pr54061 patch, fix another abort.

[Steve Ellcey]

On Tue, 2012-12-11 at 21:52 +, Richard Sandiford wrote:

  +  mips_dbx_regno[CPRESTORE_SLOT_REGNUM] = IGNORED_DWARF_REGNUM;


 If even fake registers like these are going to be used, then I think
 we should initialise to IGNORED_DWARF_REGNUM rather than INVALID_REGNUM in:
 
   for (i = 0; i  FIRST_PSEUDO_REGISTER; i++)
 {
   mips_dbx_regno[i] = INVALID_REGNUM;
   ...
 }
 
 and remove the ALL_COP_REG loop that was in the earlier patch.
 
 Richard

So far, this is the only fake register that I have seen show up while
building GCC, glibc, newlib, binutils, etc.  I am not sure if we want to
set all fake registers to IGNORED because of this one case.  If more
popped up then I could see us making that change.

Steve Ellcey
sell...@mips.com

Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

[Steve Ellcey]

On Mon, 2012-12-10 at 10:53 +, Richard Sandiford wrote:

 So please ignore that stupid suggestion.  The comments about the MIPS
 parts still stand of course.
 
 Richard

Here is a new patch.  I made the MIPS changes and I also changed some
code in dwarf2out.c.  I was making some calls to dbx_reg_number too
early in the last patch and getting aborts during testing due to that.
I also used a variable to avoid calling it twice in a row now.  This
version passed the GCC testsuite with no regressions.

Steve Ellcey
sell...@mips.com


2012-12-07  Steve Ellcey  sell...@mips.com

PR target/54061
rtl.h (IGNORED_DWARF_REGNUM): New.
* dwarf2out.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
(mem_loc_descriptor): Ditto.
* config/mips/mips.h (ALL_COP_REG_FIRST): New.
(ALL_COP_REG_LAST): New.
(ALL_COP_REG_NUM): Redefine using above macros.
* config/mips/mips.c (mips_option_override): Set mips_dbx_regno
coprocessor entries to IGNORED_DWARF_REGNUM.

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index b6a2290..820b228 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -16757,6 +16757,9 @@ mips_option_override (void)
   for (i = FP_REG_FIRST; i = FP_REG_LAST; i++)
 mips_dbx_regno[i] = i + start;
 
+  for (i = ALL_COP_REG_FIRST; i = ALL_COP_REG_LAST; i++)
+mips_dbx_regno[i] = IGNORED_DWARF_REGNUM;
+
   /* Accumulator debug registers use big-endian ordering.  */
   mips_dbx_regno[HI_REGNUM] = MD_DBX_FIRST + 0;
   mips_dbx_regno[LO_REGNUM] = MD_DBX_FIRST + 1;
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 308b59b..60b26cb 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1641,8 +1641,11 @@ struct mips_cpu_info {
 #define COP3_REG_FIRST 144
 #define COP3_REG_LAST 175
 #define COP3_REG_NUM (COP3_REG_LAST - COP3_REG_FIRST + 1)
-/* ALL_COP_REG_NUM assumes that COP0,2,and 3 are numbered consecutively.  */
-#define ALL_COP_REG_NUM (COP3_REG_LAST - COP0_REG_FIRST + 1)
+
+/* These definitions assume that COP0, 2 and 3 are numbered consecutively.  */
+#define ALL_COP_REG_FIRST COP0_REG_FIRST
+#define ALL_COP_REG_LAST COP3_REG_LAST
+#define ALL_COP_REG_NUM (ALL_COP_REG_LAST - ALL_COP_REG_FIRST + 1)
 
 #define DSP_ACC_REG_FIRST 176
 #define DSP_ACC_REG_LAST 181
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f0256ae..c92fa4b 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10499,7 +10499,12 @@ reg_loc_descriptor (rtx rtl, enum var_init_status 
initialized)
   if (hard_regno_nregs[REGNO (rtl)][GET_MODE (rtl)]  1 || regs)
 return multiple_reg_loc_descriptor (rtl, regs, initialized);
   else
-return one_reg_loc_descriptor (dbx_reg_number (rtl), initialized);
+{
+  unsigned int dbx_regnum = dbx_reg_number (rtl);
+  if (dbx_regnum == IGNORED_DWARF_REGNUM)
+   return 0;
+  return one_reg_loc_descriptor (dbx_regnum, initialized);
+}
 }
 
 /* Return a location descriptor that designates a machine register for
@@ -11926,6 +11931,7 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
  ))
{
  dw_die_ref type_die;
+ unsigned int dbx_regnum;
 
  if (dwarf_strict)
break;
@@ -11935,8 +11941,12 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
 GET_MODE_CLASS (mode) == MODE_INT);
  if (type_die == NULL)
break;
+
+ dbx_regnum = dbx_reg_number (rtl);
+ if (dbx_regnum == IGNORED_DWARF_REGNUM)
+   break;
  mem_loc_result = new_loc_descr (DW_OP_GNU_regval_type,
- dbx_reg_number (rtl), 0);
+ dbx_regnum, 0);
  mem_loc_result-dw_loc_oprnd2.val_class = dw_val_class_die_ref;
  mem_loc_result-dw_loc_oprnd2.v.val_die_ref.die = type_die;
  mem_loc_result-dw_loc_oprnd2.v.val_die_ref.external = 0;
@@ -12138,9 +12148,13 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
op0 = mem_loc_descriptor (ENTRY_VALUE_EXP (rtl), mode,
  VOIDmode, VAR_INIT_STATUS_INITIALIZED);
  else
-   op0
- = one_reg_loc_descriptor (dbx_reg_number (ENTRY_VALUE_EXP (rtl)),
-   VAR_INIT_STATUS_INITIALIZED);
+   {
+  unsigned int dbx_regnum = dbx_reg_number (ENTRY_VALUE_EXP (rtl));
+ if (dbx_regnum == IGNORED_DWARF_REGNUM)
+   return NULL;
+ op0 = one_reg_loc_descriptor (dbx_regnum,
+   VAR_INIT_STATUS_INITIALIZED);
+   }
}
   else if (MEM_P (ENTRY_VALUE_EXP (rtl))
REG_P (XEXP (ENTRY_VALUE_EXP (rtl), 0)))
diff --git a/gcc/rtl.h b/gcc/rtl.h
index a0fb4f7..5b9ceb8 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2439,6 +2439,9 @@ extern rtx gen_rtx_MEM (enum machine_mode, rtx);
 /* REGNUM never

[patch, mips, testsuite] Fix scan on gcc.target/mips/ext-2.c

[Steve Ellcey]

In looking at the failure of gcc.target/mips/ext-2.c, it looks like the
GCC compiler is now figuring out that it can use a 32 bit ext instruction
instead of a 64 bit dext instruction and that this is why the test
fails.  Here is a patch to look for 'ext' or 'dext', OK to checkin?
It fixes the failure for me and I see no reason why GCC should not use
the ext instruction instead of dext in this case.

Steve Ellcey
sell...@mips.com


2012-12-10  Steve Ellcey  sell...@mips.com

* gcc.target/mips/ext-2.c: Scan for ext or dext.


diff --git a/gcc/testsuite/gcc.target/mips/ext-2.c 
b/gcc/testsuite/gcc.target/mips/ext-2.c
index 5d68bc5..6063d3b 100644
--- a/gcc/testsuite/gcc.target/mips/ext-2.c
+++ b/gcc/testsuite/gcc.target/mips/ext-2.c
@@ -4,7 +4,7 @@
 /* { dg-do compile } */
 /* { dg-options isa_rev=2 -mgp64 } */
 /* { dg-skip-if code quality test { *-*-* } { -O0 } {  } } */
-/* { dg-final { scan-assembler \tdext\t } } */
+/* { dg-final { scan-assembler \t(dext|ext)\t } } */
 /* { dg-final { scan-assembler-not \tand } } */
 /* { dg-final { scan-assembler-not \td?srl } } */
 

[patch, mips] Fix -mno-shared option (gcc.target/mips/pr35802.c)

[Steve Ellcey]

The test gcc.target/mips/pr35802.c is failing with the message:

xgcc: error: unrecognized command line option '-mdsp-mno-shared'

Obviously the -mdsp and -mno-shared flags got stuck together without
a space between them.  This patch fixes the failure.  Ok to checkin?
It was tested with no regressions.

2012-12-10  Steve Ellcey  sell...@mips.com

* config/mips/gnu-user.h (NO_SHARED_SPECS): Add space before option.


diff --git a/gcc/config/mips/gnu-user.h b/gcc/config/mips/gnu-user.h
index d35ddac..55ca662 100644
--- a/gcc/config/mips/gnu-user.h
+++ b/gcc/config/mips/gnu-user.h
@@ -97,7 +97,7 @@ along with GCC; see the file COPYING3.  If not see
 #ifdef HAVE_AS_NO_SHARED
 /* Default to -mno-shared for non-PIC.  */
 # define NO_SHARED_SPECS \
-  %{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;:-mno-shared}
+  %{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;: -mno-shared}
 #else
 # define NO_SHARED_SPECS 
 #endif

[patch, testsuite] Fix pr35634 tests when char is unsigned.

[Steve Ellcey]

The tests gcc.dg/torture/pr35634.c and g++.dg/torture/pr35634.C fail for
me on the mips-mti-elf target.  At first I thought it was because 'n'
was not initialized but then I realized it was because 'char' on this
target defaults to 'unsigned char', not 'signed char'.  Since I think
initializing 'n' is still a good idea I made that change as well as making
'c' an explicitly signed char.  This now passes on mips-mti-elf.

OK for checkin?

Steve Ellcey
sell...@mips.com


2012-12-10  Steve Ellcey  sell...@mips.com

* gcc.dg/torture/pr35634.c: Initialize n, make c signed.
* g++.dg/torgure/pr35634.C: Ditto.

diff --git a/gcc/testsuite/g++.dg/torture/pr35634.C 
b/gcc/testsuite/g++.dg/torture/pr35634.C
index 00848e3..1f03bb1 100644
--- a/gcc/testsuite/g++.dg/torture/pr35634.C
+++ b/gcc/testsuite/g++.dg/torture/pr35634.C
@@ -5,7 +5,7 @@ extern C void exit (int);
 
 void foo (int i)
 {
-static int n;
+static int n = 0;
 if (i  -128 || i  127)
 abort ();
 if (++n  1000)
@@ -14,6 +14,6 @@ void foo (int i)
 
 int main ()
 {
-char c;
+signed char c;
 for (c = 0; ; c++) foo (c);
 }
diff --git a/gcc/testsuite/gcc.dg/torture/pr35634.c 
b/gcc/testsuite/gcc.dg/torture/pr35634.c
index 32df7d4..f8876a4 100644
--- a/gcc/testsuite/gcc.dg/torture/pr35634.c
+++ b/gcc/testsuite/gcc.dg/torture/pr35634.c
@@ -5,7 +5,7 @@ void exit (int);
 
 void foo (int i)
 {
-static int n;
+static int n = 0;
 if (i  -128 || i  127)
 abort ();
 if (++n  1000)
@@ -14,6 +14,6 @@ void foo (int i)
 
 int main ()
 {
-char c;
+signed char c;
 for (c = 0; ; c++) foo (c);
 }

Re: [patch, testsuite] Fix pr35634 tests when char is unsigned.

[Steve Ellcey]

On Mon, 2012-12-10 at 20:01 +0100, Richard Biener wrote:

 
 Ok minus the initialization.
 
 Thanks,
 Richard.

Actually, it looks like you already fixed this last week.  I am not
seeing it in my git tree, but it is in the FSF subversion and
git trees so I think I have a local problem updating my tree.

Steve Ellcey
sell...@mips.com

[patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

[Steve Ellcey]

This is my attempt to fix PR 54061, a bug where GCC aborts while trying to
put out debug information for a co-processor register.  My understanding is
that gdb cannot access the coprocessor registers and so there is no valid
debug information that can be put out for this case.  So my fix is to remove
the assert from dbx_reg_number and change the callers to check for a
INVALID_REGNUM value coming from dbx_reg_number.  If they get this value
then they do not put out any debug information for the register.  I have
tested this on gcc.c-torture/compile/mipscop-[1234].c and it fixes the abort.

I haven't done a full regression test but will do that shortly, in the mean
time I wanted to see if this approach was considered acceptable and if not,
how I should fix it?

Steve Ellcey
sell...@mips.com


2012-12-07  Steve Ellcey  sell...@mips.com

PR target/54061
* dwarfwout.c (dbx_reg_number): Remove assert.
(reg_loc_descriptor): Check for INVALID_REGNUM.
(mem_loc_descriptor): Ditto.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f0256ae..7d26e7e 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10438,7 +10438,6 @@ dbx_reg_number (const_rtx rtl)
 #endif
 
   regno = DBX_REGISTER_NUMBER (regno);
-  gcc_assert (regno != INVALID_REGNUM);
   return regno;
 }
 
@@ -10473,6 +10472,9 @@ reg_loc_descriptor (rtx rtl, enum var_init_status 
initialized)
   if (REGNO (rtl) = FIRST_PSEUDO_REGISTER)
 return 0;
 
+  if (dbx_reg_number(rtl) == INVALID_REGNUM)
+return 0;
+
   /* We only use frame base when we're sure we're talking about the
  post-prologue local stack frame.  We do this by *not* running
  register elimination until this point, and recognizing the special
@@ -11931,6 +11933,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
break;
  if (REGNO (rtl)  FIRST_PSEUDO_REGISTER)
break;
+ if (dbx_reg_number (rtl) == INVALID_REGNUM)
+   break;
  type_die = base_type_for_mode (mode,
 GET_MODE_CLASS (mode) == MODE_INT);
  if (type_die == NULL)
@@ -12133,6 +12137,9 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
return NULL;
   if (REG_P (ENTRY_VALUE_EXP (rtl)))
{
+ if (dbx_reg_number (ENTRY_VALUE_EXP (rtl)) == INVALID_REGNUM)
+   return NULL;
+
  if (GET_MODE_CLASS (mode) != MODE_INT
  || GET_MODE_SIZE (mode)  DWARF2_ADDR_SIZE)
op0 = mem_loc_descriptor (ENTRY_VALUE_EXP (rtl), mode,

Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

[Steve Ellcey]

On Fri, 2012-12-07 at 14:43 -0800, H.J. Lu wrote:

  I think you need a way to tell a bad register from a good register
  which doesn't have DWARF register number.
 
 
 Something like
 
 #define IGNORED_DWARF_REGNUM(INVALID_REGNUM - 1)

The other option would be to have a new macro that returned true or
false if a register had a dbx register number.

#define VALID_DBX_REGNUM(regno) (true)

and check that instead of checking the return of dbx_reg_number().

A target would override this default definition of VALID_DBX_REGNUM
for registers it wanted to ignore.  It should probably be a target
macro but so should DBX_REGISTER_NUMBER and DWARF_FRAME_REGNUM, we
probably don't want to be making that change at this time in the release
cycle.

Steve Ellcey
sell...@mips.com

Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

[Steve Ellcey]

 On Fri, 2012-12-07 at 14:43 -0800, H.J. Lu wrote:

  I think you need a way to tell a bad register from a good register
  which doesn't have DWARF register number.

Here is a patch using your IGNORED_DWARF_REGNUM idea.

Steve Ellcey
sell...@mips.com


2012-12-07  Steve Ellcey  sell...@mips.com

PR target/54061
* rtl.h (IGNORED_DWARF_REGNUM): New.
* dwarfwout.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
(mem_loc_descriptor): Ditto.
* config/mips/mips.c (mips_option_override): Set mips_dbx_regno
coprocessor entries to IGNORED_DWARF_REGNUM.


diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index b6a2290..bc99f29 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -16757,6 +16757,9 @@ mips_option_override (void)
   for (i = FP_REG_FIRST; i = FP_REG_LAST; i++)
 mips_dbx_regno[i] = i + start;
 
+  for (i = COP0_REG_FIRST; i = COP3_REG_LAST; i++)
+mips_dbx_regno[i] = IGNORED_DWARF_REGNUM;
+
   /* Accumulator debug registers use big-endian ordering.  */
   mips_dbx_regno[HI_REGNUM] = MD_DBX_FIRST + 0;
   mips_dbx_regno[LO_REGNUM] = MD_DBX_FIRST + 1;
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f0256ae..caedb5f 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10473,6 +10473,9 @@ reg_loc_descriptor (rtx rtl, enum var_init_status 
initialized)
   if (REGNO (rtl) = FIRST_PSEUDO_REGISTER)
 return 0;
 
+  if (dbx_reg_number(rtl) == IGNORED_DWARF_REGNUM)
+return 0;
+
   /* We only use frame base when we're sure we're talking about the
  post-prologue local stack frame.  We do this by *not* running
  register elimination until this point, and recognizing the special
@@ -11931,6 +11934,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
break;
  if (REGNO (rtl)  FIRST_PSEUDO_REGISTER)
break;
+ if (dbx_reg_number(rtl) == IGNORED_DWARF_REGNUM)
+   break;
  type_die = base_type_for_mode (mode,
 GET_MODE_CLASS (mode) == MODE_INT);
  if (type_die == NULL)
@@ -12133,6 +12138,9 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
return NULL;
   if (REG_P (ENTRY_VALUE_EXP (rtl)))
{
+ if (dbx_reg_number (ENTRY_VALUE_EXP (rtl)) == IGNORED_DWARF_REGNUM)
+   return NULL;
+
  if (GET_MODE_CLASS (mode) != MODE_INT
  || GET_MODE_SIZE (mode)  DWARF2_ADDR_SIZE)
op0 = mem_loc_descriptor (ENTRY_VALUE_EXP (rtl), mode,
diff --git a/gcc/rtl.h b/gcc/rtl.h
index a0fb4f7..5b9ceb8 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2439,6 +2439,9 @@ extern rtx gen_rtx_MEM (enum machine_mode, rtx);
 /* REGNUM never really appearing in the INSN stream.  */
 #define INVALID_REGNUM (~(unsigned int) 0)
 
+/* REGNUM for which no debug information can be generated.  */
+#define IGNORED_DWARF_REGNUM(INVALID_REGNUM - 1)
+
 extern rtx output_constant_def (tree, int);
 extern rtx lookup_constant_def (tree);
 

Re: [IA-64] Fix dynamic allocation in leaf functions

[Steve Ellcey]

On Mon, 2012-12-03 at 13:16 +0100, Eric Botcazou wrote:
  2012-11-19  Eric Botcazou  ebotca...@adacore.com
  
  * config/ia64/ia64.c (ia64_compute_frame_size): Allocate the scratch
  area if the function allocates dynamic stack space.
  (ia64_initial_elimination_offset): Adjust offsets to above change.
 
 Ping: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01617.html
 
 Thanks in advance.


Eric, this looks OK to me.  As for back porting it, that is OK with me
too as long as it is OK with the release/branch managers.

Steve Ellcey
sell...@mips.com

[patch, libgcc] Bug in fp-bit.c when NO_NANS is defined

[Steve Ellcey]

While investigating some soft-float issues I tried compiling fp-bit.c in
libgcc with NO_NANS defined.  I wound up with an undefined reference to
makenan.

Here is my attempt at a patch to fix the problem but I am not sure if
returning 0 is the right thing to do for b/0 when NO_NANS is defined.

isinf is always going to be false when NO_NANS is defined so it
is only a question of what to do for iszero(a) that we need to worry
about. b at this point may or may not be zero.

OK to checkin or should I return something else?

Steve Ellcey
sell...@mips.com


2012-11-30  Steve Ellcey  sell...@mips.com

* fp-bit.c (_fpdiv_parts): Do not call makenan if NO_NANS defined.


diff --git a/libgcc/fp-bit.c b/libgcc/fp-bit.c
index 7509f76..10a6b3a 100644
--- a/libgcc/fp-bit.c
+++ b/libgcc/fp-bit.c
@@ -979,8 +979,10 @@ _fpdiv_parts (fp_number_type * a,
 
   if (isinf (a) || iszero (a))
 {
+#ifndef NO_NANS
   if (a-class == b-class)
return makenan ();
+#endif
   return a;
 }
 

[patch, pch] Fix pch failure on mips-mti-linux-gnu

[Steve Ellcey]

While working on PR 55399 (pch broken on mips-mti-linux-gnu) I traced
through the execution of test gcc.dg/pch/common-1.c and in comparing r192714
and r192715 I found that in the earlier version the compiler gets to
pch_open_file (with common-1.h) and does this check:

  if (pfile-all_files
   pfile-all_files-next_file) {

it finds that pfile-all_files-next_file is NULL and continues on in the
routine.

In the new version there is:

  if (pfile-all_files
   pfile-all_files-next_file
   !pfile-all_files-next_file-implicit_preinclude) {

and here it finds that pfile-all_files-next_file is true but
pfile-all_files-next_file-implicit_preinclude is false so it exits
the routine and this is why the code compiler doesn't find the
preprocessed header file.

Looking at pfile I see that pfile-all_files is pointing at stdc-predef.h
where implicit_preinclude is true but pfile-all_files-next_file is pointing
at common-1.c where implicit_preinclude is false.

My best guess as to why this is happening for me and not other people is that
the order of common-1.c and stdc-predef.h in this linked list is dependent on
how things are put into pfile-file_hash and for some reason stdc-predef.h
shows up before common-1.c for me but not for other people, where they get
common-1.c and then stdc-predef.h.

This patch checks for implicit_preinclude on both pfile-all_files and
pfile-all_files-next_file and it fixes the problem for me.  I tested
it on mips-mti-linux-gnu and had no regressions.

OK to checkin?

Steve Ellcey
sell...@mips.com



2012-11-21  Steve Ellcey  sell...@mips.com

PR pch/55399
* files.c (pch_open_file): Fix check for implicit_preinclude.


diff --git a/libcpp/files.c b/libcpp/files.c
index a8288dc..9f84d8c 100644
--- a/libcpp/files.c
+++ b/libcpp/files.c
@@ -295,7 +295,8 @@ pch_open_file (cpp_reader *pfile, _cpp_file *file, bool 
*invalid_pch)
  file or the command-line it is not a valid use of PCH.  */
   if (pfile-all_files
pfile-all_files-next_file
-   !pfile-all_files-next_file-implicit_preinclude)
+   !(pfile-all_files-implicit_preinclude
+  || pfile-all_files-next_file-implicit_preinclude))
 return false;
 
   flen = strlen (path);

Re: ping - Re: [patch] [ia64] add multiarch definitions for ia64-linux-gnu

[Steve Ellcey]

On Wed, 2012-11-21 at 03:44 +0100, Matthias Klose wrote:
 ping, re-sending to the port maintainers
 
 Am 15.11.2012 11:57, schrieb Matthias Klose:
  Am 15.11.2012 09:51, schrieb Alexander Monakov:
  The attached patch includes t-glibc instead of t-linux in config.gcc.
  
  thanks for the pointer. updated patch attached below.

OK for ia64.

Steve Ellcey
sell...@mips.com

[patch] Performance patch for MIPS conditional move in expr.c

[Steve Ellcey]

Back in August of 2011, Richard Biener made a change affecting COND_EXPRs
(r178408).  As a result of that change the GCC MIPS compiler that used
to promote HImode variables to SImode and then put out SImode variables
and assignments for the conditional move (MIPS doesn't support HImode
conditional moves) started putting out HImode variables and assignments and
the resulting code is slower then it was.

The code that used to look like this:

(insn 23 22 24 3 (set (reg/v:SI 231 [ a2+-2 ]) (zero_extend:SI (subreg:HI 
(reg:SI 320) 2))) x.c:11 -1 (nil))
(insn 27 26 28 3 (set (reg/v:SI 233 [ a2+-2 ]) (zero_extend:SI (subreg:HI 
(reg:SI 323) 2))) x.c:12 -1 (nil))
IF ()
(insn 30 241 31 4 (set (reg:SI 324) (reg/v:SI 231 [ a2+-2 ])) -1 (nil))
ELSE
(insn 34 242 35 5 (set (reg:SI 324) (reg/v:SI 233 [ a2+-2 ])) -1 (nil))
(insn 36 243 37 6 (set (reg/v:SI 234 [ a2+-2 ]) (reg:SI 324)) -1 (nil))



started outputting HI assignments instead:



(insn 23 22 24 3 (set (reg/v:SI 231 [ a2+-2 ]) (zero_extend:SI (subreg:HI 
(reg:SI 320) 2))) x.c:11 -1 (nil))
(insn 27 26 28 3 (set (reg/v:SI 233 [ a2+-2 ]) (zero_extend:SI (subreg:HI 
(reg:SI 323) 2))) x.c:12 -1 (nil))
IF ()
(insn 30 241 31 4 (set (reg:HI 324) (subreg/s/u:HI (reg/v:SI 231 [ 
a2+-2 ]) 2)) -1 (nil))
ELSE
(insn 34 242 35 5 (set (reg:HI 324) (subreg/s/u:HI (reg/v:SI 233 [ 
a2+-2 ]) 2)) -1 (nil))
(insn 36 243 37 6 (set (reg/v:SI 234 [ a2+-2 ]) (zero_extend:SI (reg:HI 324))) 
-1 (nil))

This resulted in an extra 'andi REG,REG,0x' instruction to implement the
final zero_extend instruction and that slowed the code down.  This patch
restores the previous behaviour by modifying expand_cond_expr_using_cmove
so that when we need to promote the mode in order to do a conditional move
we use that promoted mode in the temp that we are creating for the conditional
move.

Tested on mips-mti-elf with no regressions.

OK for checkin?

Steve Ellcey
sell...@mips.com


2012-11-14  Steve Ellcey  sell...@mips.com

* expr.c (expand_cond_expr_using_cmove): Use promoted mode for temp.


diff --git a/gcc/expr.c b/gcc/expr.c
index cbf3a40..b1b83d0 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7840,15 +7840,17 @@ expand_cond_expr_using_cmove (tree treeop0 
ATTRIBUTE_UNUSED,
   int unsignedp = TYPE_UNSIGNED (type);
   enum machine_mode mode = TYPE_MODE (type);
 
-  temp = assign_temp (type, 0, 1);
-
   /* If we cannot do a conditional move on the mode, try doing it
  with the promoted mode. */
   if (!can_conditionally_move_p (mode))
-mode = promote_mode (type, mode, unsignedp);
-
-  if (!can_conditionally_move_p (mode))
-return NULL_RTX;
+{
+  mode = promote_mode (type, mode, unsignedp);
+  if (!can_conditionally_move_p (mode))
+   return NULL_RTX;
+  temp = assign_temp (type, 0, 0); /* Use promoted mode for temp.  */
+}
+  else
+temp = assign_temp (type, 0, 1);
 
   start_sequence ();
   expand_operands (treeop1, treeop2,

Re: [patch] Performance patch for MIPS conditional move in expr.c

[Steve Ellcey]

On Wed, 2012-11-14 at 11:15 -0800, Andrew Pinski wrote:

 Do you have a testcase?  As I added expand_cond_expr_using_cmove, I
 think this is the correct fix.
 
 Thanks,
 Andrew Pinski

Here is a cutdown test case that I have been compiling with -O3, if you
compare with and without my patch you will see fewer 'andi' instructions
with 0x are generated after my patch is applied.

Steve Ellcey
sell...@mips.com

unsigned short foo(unsigned short a1, unsigned short a2)
{
  unsigned short i, x;
  for (i = 0; i  8; i++) {
x = (a1  1) ^ (a2  1);
a1 = 1;
if (x == 1) a2 ^= 0x2006;
a2 = 1;
if (x == 1) a2 |= 0x8800;
elsea2 = 0x77ff;
  }
  return a2;
}

Re: [patch] Performance patch for MIPS conditional move in expr.c

[Steve Ellcey]

On Wed, 2012-11-14 at 12:00 -0800, Andrew Pinski wrote:

 I know exactly where this code comes from; I have looked at the
 benchmark as one of the reason why I add expand_cond_expr_using_cmove
 in the first place.  Anyways you should look into removing
 TARGET_PROMOTE_PROTOTYPES because I found that also fixes the problem
 mentioned here.
 
 Thanks,
 Andrew Pinski

Removing TARGET_PROMOTE_PROTOTYPES looks interesting but I don't know if
it is possible for compatibility reasons.  I am still looking at my
example though, I see GCC doing:

andi$5,$5,0x1
xori$5,$5,0x1
movz$2,$4,$5

When it should just do:

andi$5,$5,0x1
movn$2,$4,$5


Steve Ellcey
sell...@mips.com

[patch, mips] Do not make -Os the default with mips-mti-elf target.

[Steve Ellcey]

I noticed that because my new mips-mti-elf target includes config/mt-sde
it uses the -Os option by default when building runtime libraries.  I would
like to remove the use of -Os so that the runtime performance for the
mips-mti-elf target is improved.  If users want the -Os flag they can use
the existing --enable-target-optspace configure option to get it.

This patch creates config/mt-mti that is like mt-sde but without -Os and
changes the mips*-mti-elf* target to use that include file instead of mt-sde.

Tested with the mips-mti-elf target.

OK to checkin?

Steve Ellcey
sell...@mips.com


2012-11-07  Steve Ellcey  sell...@mips.com

* config/mt-mti: New file.
* configure.ac (mips*-mti-elf*): Use config/mt-mti.
* configure: Regenerate.


diff --git a/config/mt-mti b/config/mt-mti
new file mode 100644
index 000..85ad9e7
--- /dev/null
+++ b/config/mt-mti
@@ -0,0 +1,13 @@
+# We use -minterlink-mips16 so that the non-MIPS16 libraries can still be
+# linked against partly-MIPS16 code.  The -mcode-readable=pcrel option allows
+# MIPS16 libraries to run on Harvard-style split I/D memories, so long
+# as they have the D-to-I redirect for PC-relative loads.  -mno-gpopt
+# has two purposes: it allows libraries to be used in situations where
+# $gp != our _gp, and it allows them to be built with -G8 while
+# retaining link compatibility with -G0 and -G4.
+#
+# We do not default to -Os like mt-sde does, users who want that can configure
+# with --enable-target-optspace.
+
+CFLAGS_FOR_TARGET += -minterlink-mips16 -mcode-readable=pcrel -mno-gpopt
+CXXFLAGS_FOR_TARGET += -minterlink-mips16 -mcode-readable=pcrel -mno-gpopt
diff --git a/configure.ac b/configure.ac
index c346c2c..a87185a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2299,9 +2299,12 @@ case ${target} in
   spu-*-*)
 target_makefile_frag=config/mt-spu
 ;;
-  mips*-sde-elf* | mips*-mti-elf*)
+  mips*-sde-elf*)
 target_makefile_frag=config/mt-sde
 ;;
+  mips*-mti-elf*)
+target_makefile_frag=config/mt-mti
+;;
   mipsisa*-*-elfoabi*)
 target_makefile_frag=config/mt-mips-elfoabi
 ;;

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

On Mon, 2012-11-05 at 23:22 +, Richard Sandiford wrote:

 No, same here: I don't use --with-sysroot for the newlib targets.
 Do you build a unified gcc+newlib tree?  If not, I don't think
 the above boilerplate works; you'll have to use something else
 instead.  E.g. install newlib first, change your board files
 to match your build tree setup, or add links from the gcc build
 directory to the newlib one.  But unified trees are simpler really
 (i.e. a newlib and libgloss symlink in the gcc tree).

 Richard

It looks like using --with-sysroot and --with-build-sysroot took care of
the problem so my patch is not needed.

Steve Ellcey
sell...@mips.com

[patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

The test gcc.dg/torture/mips-sdata-1.c fails when compiled with
-fno-fat-lto-objects because when that option is used no assembly code
is output and thus the scan does not find the '.sdata' line.

Checked with the mips-mti-elf target.  OK to checkin?

Steve Ellcey
sell...@mips.com

2012-11-05  Steve Ellcey  sell...@mips.com

* gcc.dg/torture/mips-sdata-1.c: Skip on -fno-fat-lto-objects.


diff --git a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c 
b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
index 8ffd4d8..53c9e4f 100644
--- a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
+++ b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
@@ -1,6 +1,7 @@
 /* Check that sdata-accesses are applied regardless of size or ABI.  */
 /* { dg-options -mexplicit-relocs } */
 /* { dg-do compile { target mips*-*-elf* } } */
+/* { dg-skip-if  { *-*-* } { -fno-fat-lto-objects } {  } } */
 
 struct s { int x[4]; };
 struct s my_struct __attribute__((__section__(.sdata)));

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

On Mon, 2012-11-05 at 20:38 +, Richard Sandiford wrote:

 This sort of thing should usually be handled automatically by
 scan-assembler, and is for me:
 
 /foo/gcc/xgcc -B/foo/gcc/ /bar/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c  
 -fno-diagnostics-show-caret 
 -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -mexplicit-relocs 
 -ffat-lto-objects -S  
 -isystem /foo/mipsisa64-elf/soft-float/newlib/targ-include -isystem 
 /bar/newlib/libc/include  -EB
 -msoft-float -o mips-sdata-1.s
 
 So the test passes all variations here.  I wonder what's different in
 your case?
 
 Richard

Well that is weird.  I took out my change and I still see the error:

Executing on
host: /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/xgcc
-B/local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/ 
/local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c 
 -fno-diagnostics-show-caret   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -mexplicit-relocs -S-o mips-sdata-1.s(timeout = 
300)
spawn /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/xgcc
-B/local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/ 
/local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c 
-fno-diagnostics-show-caret -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects 
-mexplicit-relocs -S -o mips-sdata-1.s^M
PASS: gcc.dg/torture/mips-sdata-1.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.dg/torture/mips-sdata-1.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects   scan-assembler gp_?rel\\(my_struct


Do you know where the -ffat-lto-objects option in your run came from?  I
don't have that in my results and my tree is up-to-date.

Steve

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

On Mon, 2012-11-05 at 21:28 +, Richard Sandiford wrote:

 Does it work for you if you run it separately?  E.g. with:
 
 make check-gcc RUNTESTFLAGS=dg-torture.exp=mips-sdata-1.c
 
 Richard

Hm, I configured GCC with '--enable-languages=c,c++', I think this might
set ENABLE_LTO to '0' and cause check_effective_target_lto to return
FALSE and cause the -ffat-lto-objects flag to not be added.  Of course
this raises the question of why it is trying to do lto testing if I
didn't configure it in.  I will add 'lto' to my configure line and see
if that fixes the problem.

Steve Ellcey
sell...@mips.com