[OpenRISC] [PATCH v2 0/5] OpenRISC updates for 10 (fpu, fixes)

[OpenRISC] [PATCH v2 0/5] OpenRISC updates for 10 (fpu, fixes)

[Stafford Horne]

Hello,

It's been about 2 months since I last sent these patches.  Sorry for the delay
I ended up getting side tracked finishing the new OpenRISC architecture spec
revision.

New since v1:
 - Changed 64-bit FPU operations to use explicit register pairs as per spec
   revision suggested by Richard Henderson.
 - Added patch for new -mrori option
 - Added patch for msoft-div fix from other series (no changes)
 - Fixed volatile spelling pointed out by Bernhard 
   Reutner-Fischer <rep.dot.nop@gmail.com>

This is a set of patches to bring FPU support to the OpenRISC backend.  The
backend also add support for 64-bit floating point operations on 32-bit cores
using register pairs, see orfpx64a32 [0].

This binutils patches are already upstream.

The toolchain has been tested using the gcc and binutils testsuites as well as
floating point test suites running on sim and an fpga soft core or1k_marocchino.
[1]

I have also included a few fixes to PRs:

 - 90362 or1k: Soft divide does not work correctly
 - 90363 or1k: Extra mask insn after load from memory

This whole patch series can be found on my github repo [2] as well.

If all is OK, I plan to commit these to master (gcc 10).  Then back port the PR
fixes to the GCC 9 branch, I will ask for guidance when I start to do the
backporting.

-Stafford

[0] https://openrisc.io/proposals/orfpx64a32
[1] https://github.com/openrisc/or1k_marocchino
[2] git at github.com:stffrdhrn/gcc.git or1k-fpu-2

Stafford Horne (5):
  or1k: Fix code quality for volatile memory loads
  or1k: Fix issues with msoft-div
  or1k: Add mrori option, fix option docs
  or1k: Initial support for FPU
  or1k: only force reg for immediates

 gcc/config.gcc                            |   2 +
 gcc/config/or1k/constraints.md            |   4 +
 gcc/config/or1k/elf.opt                   |   6 +-
 gcc/config/or1k/or1k.c                    |  48 ++++++--
 gcc/config/or1k/or1k.h                    |   3 +
 gcc/config/or1k/or1k.md                   | 129 ++++++++++++++++++++--
 gcc/config/or1k/or1k.opt                  |  78 +++++++++----
 gcc/config/or1k/predicates.md             |  23 ++++
 gcc/doc/invoke.texi                       |  77 ++++++++-----
 gcc/testsuite/gcc.target/or1k/div-mul-3.c |  31 ++++++
 gcc/testsuite/gcc.target/or1k/ror-4.c     |   8 ++
 gcc/testsuite/gcc.target/or1k/shftimm-1.c |   8 +-
 gcc/testsuite/gcc.target/or1k/swap-1.c    |  70 ++++++++++++
 gcc/testsuite/gcc.target/or1k/swap-2.c    |  47 ++++++++
 libgcc/config/or1k/lib1funcs.S            |   6 +-
 15 files changed, 465 insertions(+), 75 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/or1k/div-mul-3.c
 create mode 100644 gcc/testsuite/gcc.target/or1k/ror-4.c
 create mode 100644 gcc/testsuite/gcc.target/or1k/swap-1.c
 create mode 100644 gcc/testsuite/gcc.target/or1k/swap-2.c

-- 
2.21.0

[OpenRISC] [PATCH v2 1/5] or1k: Fix code quality for volatile memory loads

[Stafford Horne]

Volatile memory does not match the memory_operand predicate.  This
causes extra extend/mask instructions instructions when reading
from volatile memory.  On OpenRISC loading volatile memory can be
treated the same as regular memory loads which supports combined
sign/zero extends.  Fixing this eliminates the need for extra
extend/mask instructions.

This also adds a test provided by Richard Selvaggi which uncovered the
issue while we were looking into another issue.

gcc/ChangeLog:

	PR target/90363
	* config/or1k/or1k.md (zero_extend<mode>si2): Update predicate.
	(extend<mode>si2): Update predicate.
	* gcc/config/or1k/predicates.md (volatile_mem_operand): New.
	(reg_or_mem_operand): New.

gcc/testsuite/ChangeLog:

	PR target/90363
	* gcc.target/or1k/swap-1.c: New test.
	* gcc.target/or1k/swap-2.c: New test.
---
Since v1:
 - Fixed typos with volatile

 gcc/config/or1k/or1k.md                |  6 +--
 gcc/config/or1k/predicates.md          | 18 +++++++
 gcc/testsuite/gcc.target/or1k/swap-1.c | 70 ++++++++++++++++++++++++++
 gcc/testsuite/gcc.target/or1k/swap-2.c | 47 +++++++++++++++++
 4 files changed, 138 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/or1k/swap-1.c
 create mode 100644 gcc/testsuite/gcc.target/or1k/swap-2.c

diff --git a/gcc/config/or1k/or1k.md b/gcc/config/or1k/or1k.md
index 2dad51cd46b..757d899c442 100644
--- a/gcc/config/or1k/or1k.md
+++ b/gcc/config/or1k/or1k.md
@@ -328,11 +328,11 @@
 ;; Sign Extending
 ;; -------------------------------------------------------------------------
 
-;; Zero extension can always be done with AND and an extending load.
+;; Zero extension can always be done with AND or an extending load.
 
 (define_insn "zero_extend<mode>si2"
   [(set (match_operand:SI 0 "register_operand"                     "=r,r")
-	(zero_extend:SI (match_operand:I12 1 "nonimmediate_operand" "r,m")))]
+	(zero_extend:SI (match_operand:I12 1 "reg_or_mem_operand" "r,m")))]
   ""
   "@
    l.andi\t%0, %1, <zext_andi>
@@ -344,7 +344,7 @@
 
 (define_insn "extend<mode>si2"
   [(set (match_operand:SI 0 "register_operand"                      "=r,r")
-	(sign_extend:SI (match_operand:I12 1 "nonimmediate_operand"  "r,m")))]
+	(sign_extend:SI (match_operand:I12 1 "reg_or_mem_operand"  "r,m")))]
   "TARGET_SEXT"
   "@
    l.ext<ldst>s\t%0, %1
diff --git a/gcc/config/or1k/predicates.md b/gcc/config/or1k/predicates.md
index 879236bca49..b895f1b4228 100644
--- a/gcc/config/or1k/predicates.md
+++ b/gcc/config/or1k/predicates.md
@@ -82,3 +82,21 @@
 
 (define_predicate "equality_comparison_operator"
   (match_code "ne,eq"))
+
+;; Borrowed from rs6000
+;  Return true if the operand is in volatile memory.  Note that during the
+;; RTL generation phase, memory_operand does not return TRUE for volatile
+;; memory references.  So this function allows us to recognize volatile
+;; references where it's safe.
+(define_predicate "volatile_mem_operand"
+  (and (match_code "mem")
+       (match_test "MEM_VOLATILE_P (op)")
+       (if_then_else (match_test "reload_completed")
+	 (match_operand 0 "memory_operand")
+	 (match_test "memory_address_p (mode, XEXP (op, 0))"))))
+
+;; Return true if the operand is a register or memory; including volatile
+;; memory.
+(define_predicate "reg_or_mem_operand"
+  (ior (match_operand 0 "nonimmediate_operand")
+       (match_operand 0 "volatile_mem_operand")))
diff --git a/gcc/testsuite/gcc.target/or1k/swap-1.c b/gcc/testsuite/gcc.target/or1k/swap-1.c
new file mode 100644
index 00000000000..4c179d1e430
--- /dev/null
+++ b/gcc/testsuite/gcc.target/or1k/swap-1.c
@@ -0,0 +1,70 @@
+/* { dg-do run } */
+/* { dg-options "-Os -mhard-mul -msoft-div -msoft-float" } */
+
+/* Notes:
+
+   This test failed on or1k GCC 7.2.0, and passes on or1k GCC 5.3.0
+   as well as the or1k port released in GCC 9.1.
+
+   The main program is organized as a loop structure so gcc does not
+   optimize-away the calls to swap_1().  Compiling with -O2 is still smart
+   enough to optimize-away the calls, but using -Os does not.
+   The bad code is only generated when compiled with -Os.
+
+   When the bad code is generated all code is okay except for the very last
+   instruction (a 'l.addc' in the l.jr delay slot).
+   Up to that point in execution, r11 and r12 contain the correct (expected)
+   values, but the execution of the final "l.addc" corrupts r11.
+
+   This test is added to ensure this does not come back.  */
+
+#include <stdint.h>
+
+volatile static uint8_t g_doswap = 1;
+
+uint64_t swap_1 (uint64_t u64) {
+  uint32_t u64_lo, u64_hi, u64_tmp;
+
+  u64_lo = u64 & 0xFFFFFFFF;
+  u64_hi = u64 >> 32;
+
+  if (g_doswap)
+    {
+      u64_tmp = u64_lo;
+      u64_lo  = u64_hi;
+      u64_hi  = u64_tmp;
+    }
+
+  u64 = u64_lo;
+  u64 += ((uint64_t) u64_hi << 32);
+
+  return u64;
+}
+
+int main () {
+  int ret;
+  int iter;
+  uint64_t  aa[2];   // inputs to swap function
+  uint64_t  ee[2];   // expected outputs of swap function
+  uint64_t  rr[2];   // actual results of swap function
+
+  g_doswap = 1;
+
+  // populate inputs, and expected outputs:
+  aa[0] = 0x123456789abcdef0;
+  aa[1] = 0x0123456789abcdef;
+
+  ee[0] = 0x9ABCDEF012345678;
+  ee[1] = 0x89ABCDEF01234567;
+
+  ret = 0;
+  for (iter = 0; iter < 2; iter++)
+    {
+      rr[iter] = swap_1(aa[iter]);
+      // early-out if there's a mis-match:
+      if (ee[iter] != rr[iter])
+        ret = 1;
+    }
+
+  return ret;
+}
diff --git a/gcc/testsuite/gcc.target/or1k/swap-2.c b/gcc/testsuite/gcc.target/or1k/swap-2.c
new file mode 100644
index 00000000000..3730b4ee2e3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/or1k/swap-2.c
@@ -0,0 +1,47 @@
+/* { dg-do compile } */
+/* { dg-options "-Os -mhard-mul -msoft-div -msoft-float" } */
+
+/* Notes:
+
+   This test failed on or1k GCC 7.2.0, and passes on or1k GCC 5.3.0
+   as well as the or1k port released in GCC 9.1.
+
+   The main program is organized as a loop structure so gcc does not
+   optimize-away the calls to swap_1().  Compiling with -O2 is still smart
+   enough to optimize-away the calls, but using -Os does not.
+   The bad code is only generated when compiled with -Os.
+
+   When the bad code is generated all code is okay except for the very last
+   instruction (a 'l.addc' in the l.jr delay slot).
+   Up to that point in execution, r11 and r12 contain the correct (expected)
+   values, but the execution of the final "l.addc" corrupts r11.
+
+   This test ensures an l.addc is not in the output.  Also, while confirming
+   this test we uncovered PR/90363, we use it to check for that as well.  */
+
+#include <stdint.h>
+
+volatile static uint8_t g_doswap = 1;
+
+uint64_t swap_1 (uint64_t u64) {
+  uint32_t u64_lo, u64_hi, u64_tmp;
+
+  u64_lo = u64 & 0xFFFFFFFF;
+  u64_hi = u64 >> 32;
+
+  if (g_doswap)
+    {
+      u64_tmp = u64_lo;
+      u64_lo  = u64_hi;
+      u64_hi  = u64_tmp;
+    }
+
+  u64 = u64_lo;
+  u64 += ((uint64_t) u64_hi << 32);
+
+  return u64;
+}
+
+/* Check to ensure the volatile load does not get zero extended.  */
+/* { dg-final { scan-assembler-not "0xff" } } */
+/* { dg-final { scan-assembler-not "l.addc" } } */
-- 
2.21.0

[OpenRISC] [PATCH v2 2/5] or1k: Fix issues with msoft-div

[Stafford Horne]

Fixes bad assembly logic with software divide as reported by Richard Selvaggi.
Also, add a basic test to verify the soft math works when enabled.

gcc/testsuite/ChangeLog:

	PR target/90362
	* gcc.target/or1k/div-mul-3.c: New test.

libgcc/ChangeLog:

	PR target/90362
	* config/or1k/lib1funcs.S (__udivsi3): Change l.sfeqi
	to l.sfeq and l.sfltsi to l.sflts equivalents as the immediate
	instructions are not available on every processor.  Change a
	l.bnf to l.bf to fix logic issue.
---
Changes since v1:
 - none

 gcc/testsuite/gcc.target/or1k/div-mul-3.c | 31 +++++++++++++++++++++++
 libgcc/config/or1k/lib1funcs.S            |  6 ++---
 2 files changed, 34 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/or1k/div-mul-3.c

diff --git a/gcc/testsuite/gcc.target/or1k/div-mul-3.c b/gcc/testsuite/gcc.target/or1k/div-mul-3.c
new file mode 100644
index 00000000000..2c4f91b7e98
--- /dev/null
+++ b/gcc/testsuite/gcc.target/or1k/div-mul-3.c
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -msoft-div -msoft-mul" } */
+
+struct testcase {
+  int a;
+  int b;
+  int c;
+  int expected;
+};
+
+struct testcase tests[] = {
+  {2, 200, 3, 133},
+  {3, 300, 3, 300},
+  {2, 500, 3, 333},
+  {4, 250, 3, 333},
+  {0, 0, 0, 0}
+};
+
+int calc (int a, int b, int c) {
+  return a * b / c;
+}
+
+int main () {
+  int fail = 0;
+  struct testcase *tc;
+
+  for (int i = 0; (tc = &tests[i], tc->c); i++)
+    fail |= (calc (tc->a, tc->b, tc->c) != tc->expected);
+
+  return fail;
+}
diff --git a/libgcc/config/or1k/lib1funcs.S b/libgcc/config/or1k/lib1funcs.S
index d2103923486..6d058977229 100644
--- a/libgcc/config/or1k/lib1funcs.S
+++ b/libgcc/config/or1k/lib1funcs.S
@@ -68,18 +68,18 @@ __udivmodsi3_internal:
 	   is not clobbered by this routine, and use that as to
 	   save a return address without creating a stack frame.  */
 
-	l.sfeqi		r4, 0		/* division by zero; return 0.  */
+	l.sfeq		r4, r0		/* division by zero; return 0.  */
 	l.ori		r11, r0, 0	/* initial quotient */
 	l.bf		9f
 	 l.ori		r12, r3, 0	/* initial remainder */
 
 	/* Given X/Y, shift Y left until Y >= X.  */
 	l.ori		r6, r0, 1	/* mask = 1 */
-1:	l.sfltsi	r4, 0		/* y has msb set */
+1:	l.sflts		r4, r0		/* y has msb set */
 	l.bf		2f
 	 l.sfltu	r4, r12		/* y < x */
 	l.add		r4, r4, r4	/* y <<= 1 */
-	l.bnf		1b
+	l.bf		1b
 	 l.add		r6, r6, r6	/* mask <<= 1 */
 
 	/* Shift Y back to the right again, subtracting from X.  */
-- 
2.21.0

[OpenRISC] [PATCH v2 3/5] or1k: Add mrori option, fix option docs

[Stafford Horne]

gcc/ChangeLog:

	* config.gcc (or1k*-*-*): Add mrori and mror to validation.
	* doc/invoke.texi (OpenRISC Options): Add mrori option, rewrite all
	documenation to be more clear.
	* config/or1k/elf.opt (mboard=, mnewlib): Rewrite documentation to be
	more clear.
	* config/or1k/or1k.opt (mrori): New option.
	(mhard-div, msoft-div, mhard-mul, msoft-mul, mcmov, mror, msext,
	msfimm, mshftimm): Rewrite documentation to be more clear.
	* config/or1k/or1k.md (insn_support): Add ror and rori.
	(enabled): Add conditions for ror and rori.
	(rotrsi3): Replace condition for shftimm with ror and rori.

gcc/testsuite/ChangeLog:

	* gcc.target/or1k/ror-4.c: New file.
	* gcc.target/or1k/shftimm-1.c: Update test from rotate to shift
	as the shftimm option no longer controls rotate.
---
Changes since v1:
 - new patch

 gcc/config.gcc                            |  1 +
 gcc/config/or1k/elf.opt                   |  6 +--
 gcc/config/or1k/or1k.md                   | 12 +++--
 gcc/config/or1k/or1k.opt                  | 56 +++++++++++++----------
 gcc/doc/invoke.texi                       | 56 +++++++++++++----------
 gcc/testsuite/gcc.target/or1k/ror-4.c     |  8 ++++
 gcc/testsuite/gcc.target/or1k/shftimm-1.c |  8 ++--
 7 files changed, 87 insertions(+), 60 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/or1k/ror-4.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index c281c418b28..aeab8b4544e 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2578,6 +2578,7 @@ or1k*-*-*)
 	for or1k_multilib in ${or1k_multilibs}; do
 		case ${or1k_multilib} in
 		mcmov | msext | msfimm | \
+		mror | mrori | \
 		mhard-div | mhard-mul | \
 		msoft-div | msoft-mul )
 			TM_MULTILIB_CONFIG="${TM_MULTILIB_CONFIG},${or1k_multilib}"
diff --git a/gcc/config/or1k/elf.opt b/gcc/config/or1k/elf.opt
index 641b6ddd4be..2d4d1875d02 100644
--- a/gcc/config/or1k/elf.opt
+++ b/gcc/config/or1k/elf.opt
@@ -25,9 +25,9 @@
 
 mboard=
 Target RejectNegative Joined
-Configure board specific runtime.
+Configure the newlib board specific runtime.  The default is or1ksim.
 
 mnewlib
 Target RejectNegative
-For compatibility, it's always newlib for elf now.
-
+This option is ignored; it is provided for compatibility purposes only.  This
+used to select linker and preprocessor options for use with newlib.
diff --git a/gcc/config/or1k/or1k.md b/gcc/config/or1k/or1k.md
index 757d899c442..bbad593db40 100644
--- a/gcc/config/or1k/or1k.md
+++ b/gcc/config/or1k/or1k.md
@@ -63,7 +63,7 @@
   "alu,st,ld,control,multi"
   (const_string "alu"))
 
-(define_attr "insn_support" "class1,sext,sfimm,shftimm" (const_string "class1"))
+(define_attr "insn_support" "class1,sext,sfimm,shftimm,ror,rori" (const_string "class1"))
 
 (define_attr "enabled" ""
   (cond [(eq_attr "insn_support" "class1") (const_int 1)
@@ -72,7 +72,11 @@
 	 (and (eq_attr "insn_support" "sfimm")
 	      (ne (symbol_ref "TARGET_SFIMM") (const_int 0))) (const_int 1)
 	 (and (eq_attr "insn_support" "shftimm")
-	      (ne (symbol_ref "TARGET_SHFTIMM") (const_int 0))) (const_int 1)]
+	      (ne (symbol_ref "TARGET_SHFTIMM") (const_int 0))) (const_int 1)
+	 (and (eq_attr "insn_support" "ror")
+	      (ne (symbol_ref "TARGET_ROR") (const_int 0))) (const_int 1)
+	 (and (eq_attr "insn_support" "rori")
+	      (ne (symbol_ref "TARGET_RORI") (const_int 0))) (const_int 1)]
 	(const_int 0)))
 
 ;; Describe a user's asm statement.
@@ -179,11 +183,11 @@
   [(set (match_operand:SI 0 "register_operand" "=r,r")
 	(rotatert:SI (match_operand:SI 1 "register_operand"  "r,r")
 		  (match_operand:SI 2 "reg_or_u6_operand" "r,n")))]
-  "TARGET_ROR"
+  "TARGET_ROR || TARGET_RORI"
   "@
    l.ror\t%0, %1, %2
    l.rori\t%0, %1, %2"
-  [(set_attr "insn_support" "*,shftimm")])
+  [(set_attr "insn_support" "ror,rori")])
 
 (define_insn "andsi3"
   [(set (match_operand:SI 0 "register_operand" "=r,r")
diff --git a/gcc/config/or1k/or1k.opt b/gcc/config/or1k/or1k.opt
index 7bdbd842dd4..c2f64c5dd45 100644
--- a/gcc/config/or1k/or1k.opt
+++ b/gcc/config/or1k/or1k.opt
@@ -21,47 +21,55 @@
 ; See the GCC internals manual (options.texi) for a description of
 ; this file's format.
 
-; Please try to keep this file in ASCII collating order.
-
 mhard-div
 Target RejectNegative InverseMask(SOFT_DIV)
-Use hardware divide instructions, use -msoft-div for emulation.
+Enable generation of hardware divide (l.div, l.divu) instructions.  This is the
+default; use -msoft-div to override.
+
+msoft-div
+Target RejectNegative Mask(SOFT_DIV)
+Enable generation of binaries which use functions from libgcc to perform divide
+operations.  The default is -mhard-div.
 
 mhard-mul
 Target RejectNegative InverseMask(SOFT_MUL).
-Use hardware multiply instructions, use -msoft-mul for emulation.
+Enable generation of hardware multiply instructions (l.mul, l.muli) instructions.
+This is the default; use -msoft-mul to override.
+
+msoft-mul
+Target RejectNegative Mask(SOFT_MUL).
+Enable generation of binaries which use functions from libgcc to perform
+multiply operations. The default is -mhard-mul.
 
 mcmov
 Target RejectNegative Mask(CMOV)
-Allows generation of binaries which use the l.cmov instruction.  If your target
-does not support this the compiler will generate the equivalent using set and
-branch.
+Enable generation of conditional move (l.cmov) instructions.  By default the
+equivalent will be generated using using set and branch.
 
 mror
 Target RejectNegative Mask(ROR)
-Allows generation of binaries which use the l.rori instructions.
+Enable generation of rotate right (l.ror) instructions.  By default functions
+from libgcc are used to perform rotate right operations.
+
+mrori
+Target RejectNegative Mask(RORI)
+Enable generation of rotate right with immediate (l.rori) instructions.  By
+default functions from libgcc are used to perform rotate right with immediate
+operations.
 
 msext
 Target RejectNegative Mask(SEXT)
-Allows generation of binaries which use sign-extension instructions.  If your
-target does not support this the compiler will use memory loads to perform sign
-extension.
+Enable generation of sign extension (l.ext*) instructions.  By default memory
+loads are used to perform sign extension.
 
 msfimm
 Target RejectNegative Mask(SFIMM)
-Allows generation of binaries which use l.sf*i instructions.  If your target
-does not support this the compiler will generate instructions to store the
-immediate to a register first.
+Enable generation of compare and set flag with immediate (l.sf*i) instructions.
+By default extra instructions will be generated to store the immediate to a
+register first.
 
 mshftimm
 Target RejectNegative Mask(SHFTIMM)
-Allows generation of binaries which support shifts and rotate instructions
-supporting immediate arguments, for example l.rori.
-
-msoft-div
-Target RejectNegative Mask(SOFT_DIV)
-Use divide emulation.
-
-msoft-mul
-Target RejectNegative Mask(SOFT_MUL).
-Use multiply emulation.
+Enable generation of shift with immediate (l.srai, l.srli, l.slli) instructions.
+By default extra instructions will be generated to store the immediate to a
+register first.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6382a840281..1f1f73672bd 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1033,7 +1033,7 @@ Objective-C and Objective-C++ Dialects}.
 @emph{OpenRISC Options}
 @gccoptlist{-mboard=@var{name}  -mnewlib  -mhard-mul  -mhard-div @gol
 -msoft-mul  -msoft-div @gol
--mcmov  -mror  -msext  -msfimm  -mshftimm}
+-mcmov  -mror  -mrori  -msext  -msfimm  -mshftimm}
 
 @emph{PDP-11 Options}
 @gccoptlist{-mfpu  -msoft-float  -mac0  -mno-ac0  -m40  -m45  -m10 @gol
@@ -23632,50 +23632,56 @@ newlib board library linking.  The default is @code{or1ksim}.
 
 @item -mnewlib
 @opindex mnewlib
-For compatibility, it's always newlib for elf now.
+This option is ignored; it is for compatibility purposes only.  This used to
+select linker and preprocessor options for use with newlib.
 
- at item -mhard-div
+ at item -msoft-div
+ at itemx -mhard-div
+ at opindex msoft-div
 @opindex mhard-div
-Generate code for hardware which supports divide instructions.  This is the
-default.
+Select software or hardware divide (@code{l.div}, @code{l.divu}) instructions.
+This default is hardware divide.
 
- at item -mhard-mul
+ at item -msoft-mul
+ at itemx -mhard-mul
+ at opindex msoft-mul
 @opindex mhard-mul
-Generate code for hardware which supports multiply instructions.  This is the
-default.
+Select software or hardware multiply (@code{l.mul}, @code{l.muli}) instructions.
+This default is hardware multiply.
 
 @item -mcmov
 @opindex mcmov
-Generate code for hardware which supports the conditional move (@code{l.cmov})
-instruction.
+Enable generation of conditional move (@code{l.cmov}) instructions.  By
+default the equivalent will be generated using using set and branch.
 
 @item -mror
 @opindex mror
-Generate code for hardware which supports rotate right instructions.
+Enable generation of rotate right (@code{l.ror}) instructions.  By default
+functions from @file{libgcc} are used to perform rotate right operations.
+
+ at item -mrori
+ at opindex mrori
+Enable generation of rotate right with immediate (@code{l.rori}) instructions.
+By default functions from @file{libgcc} are used to perform rotate right with
+immediate operations.
 
 @item -msext
 @opindex msext
-Generate code for hardware which supports sign-extension instructions.
+Enable generation of sign extension (@code{l.ext*}) instructions.  By default
+memory loads are used to perform sign extension.
 
 @item -msfimm
 @opindex msfimm
-Generate code for hardware which supports set flag immediate (@code{l.sf*i})
-instructions.
+Enable generation of compare and set flag with immediate (@code{l.sf*i})
+instructions.  By default extra instructions will be generated to store the
+immediate to a register first.
 
 @item -mshftimm
 @opindex mshftimm
-Generate code for hardware which supports shift immediate related instructions
-(i.e. @code{l.srai}, @code{l.srli}, @code{l.slli}, @code{1.rori}).  Note, to
-enable generation of the @code{l.rori} instruction the @option{-mror} flag must
-also be specified.
+Enable generation of shift with immediate (@code{l.srai}, @code{l.srli},
+ at code{l.slli}) instructions.  By default extra instructions will be generated
+to store the immediate to a register first.
 
- at item -msoft-div
- at opindex msoft-div
-Generate code for hardware which requires divide instruction emulation.
-
- at item -msoft-mul
- at opindex msoft-mul
-Generate code for hardware which requires multiply instruction emulation.
 
 @end table
 
diff --git a/gcc/testsuite/gcc.target/or1k/ror-4.c b/gcc/testsuite/gcc.target/or1k/ror-4.c
new file mode 100644
index 00000000000..7489ce5b6a2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/or1k/ror-4.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-mrori -O2" } */
+
+unsigned int rotate6 (unsigned int a) {
+  return ( a >> 6 ) | ( a << ( 32 - 6 ) );
+}
+
+/* { dg-final { scan-assembler "l.rori" } } */
diff --git a/gcc/testsuite/gcc.target/or1k/shftimm-1.c b/gcc/testsuite/gcc.target/or1k/shftimm-1.c
index be8d9e8b895..3a8dc06df79 100644
--- a/gcc/testsuite/gcc.target/or1k/shftimm-1.c
+++ b/gcc/testsuite/gcc.target/or1k/shftimm-1.c
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
-/* { dg-options "-mror -mshftimm -O2" } */
+/* { dg-options "-mshftimm -O2" } */
 
-unsigned int rotate6 (unsigned int a) {
-  return ( a >> 6 ) | ( a << ( 32 - 6 ) );
+unsigned int shift6 (unsigned int a) {
+  return a << 6;
 }
 
-/* { dg-final { scan-assembler "l.rori" } } */
+/* { dg-final { scan-assembler "l.slli" } } */
-- 
2.21.0

[OpenRISC] [PATCH v2 4/5] or1k: Initial support for FPU

[Stafford Horne]

This adds support for OpenRISC hardware floating point instructions.
This is enabled with the -mhard-float option.

Double-prevision floating point operations work using register pairing as
specified in: https://openrisc.io/proposals/orfpx64a32.  This has just been
added in the OpenRISC architecture specification 1.3.
This is enabled with the -mdouble-float option.

Not all architectures support unordered comparisons so an option,
-munordered-float is added.

Currently OpenRISC does not support sf/df or df/sf conversions, but this has
also just been added in architecture specification 1.3.

gcc/ChangeLog:

	* config.gcc (or1k*-*-*): Add mhard-float, mdouble-float, msoft-float
	and munordered-float validations.
	* config/or1k/constraints.md (d): New register constraint.
	* config/or1k/predicates.md (fp_comparison_operator): New.
	* config/or1k/or1k.c (or1k_print_operand): Add support for printing 'd'
	operands.
	(or1k_expand_compare): Normalize unordered comparisons.
	* config/or1k/or1k.h (reg_class): Define DOUBLE_REGS.
	(REG_CLASS_NAMES): Add "DOUBLE_REGS".
	(REG_CLASS_CONTENTS): Add contents for DOUBLE_REGS.
	* config/or1k/or1k.md (type): Add fpu.
	(fpu): New instruction reservation.
	(F, f, fr, fi, FI, FOP, fop): New.
	(<fop><F:mode>3): New ALU instruction definition.
	(float<fi><F:mode>2): New conversion instruction definition.
	(fix_trunc<F:mode><fi>2): New conversion instruction definition.
	(fpcmpcc): New code iterator.
	(*sf_fp_insn): New instruction definition.
	(cstore<F:mode>4): New expand definition.
	(cbranch<F:mode>4): New expand definition.
	* config/or1k/or1k.opt (msoft-float, mhard-float, mdouble-float,
	munordered-float): New options.
	* doc/invoke.texi: Document msoft-float, mhard-float, mdouble-float and
	munordered-float.
---
Changes since v1:
 - User register pairs for 64-bit ops. See or1k_print_operand 

 gcc/config.gcc                 |   1 +
 gcc/config/or1k/constraints.md |   4 ++
 gcc/config/or1k/or1k.c         |  36 ++++++++++-
 gcc/config/or1k/or1k.h         |   3 +
 gcc/config/or1k/or1k.md        | 111 ++++++++++++++++++++++++++++++++-
 gcc/config/or1k/or1k.opt       |  22 +++++++
 gcc/config/or1k/predicates.md  |   5 ++
 gcc/doc/invoke.texi            |  21 +++++++
 8 files changed, 199 insertions(+), 4 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index aeab8b4544e..1678109131f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2579,6 +2579,7 @@ or1k*-*-*)
 		case ${or1k_multilib} in
 		mcmov | msext | msfimm | \
 		mror | mrori | \
+		mhard-float | mdouble-float | munordered-float | msoft-float | \
 		mhard-div | mhard-mul | \
 		msoft-div | msoft-mul )
 			TM_MULTILIB_CONFIG="${TM_MULTILIB_CONFIG},${or1k_multilib}"
diff --git a/gcc/config/or1k/constraints.md b/gcc/config/or1k/constraints.md
index 93da8c058c6..8cac7eb5329 100644
--- a/gcc/config/or1k/constraints.md
+++ b/gcc/config/or1k/constraints.md
@@ -24,6 +24,7 @@
 
 ; We use:
 ;  c - sibcall registers
+;  d - double pair base registers (excludes r0, r30 and r31 which overflow)
 ;  I - constant signed 16-bit
 ;  K - constant unsigned 16-bit
 ;  M - constant signed 16-bit shifted left 16-bits (l.movhi)
@@ -32,6 +33,9 @@
 (define_register_constraint "c" "SIBCALL_REGS"
   "Registers which can hold a sibling call address")
 
+(define_register_constraint "d" "DOUBLE_REGS"
+  "Registers which can be used for double reg pairs.")
+
 ;; Immediates
 (define_constraint "I"
   "A signed 16-bit immediate in the range -32768 to 32767."
diff --git a/gcc/config/or1k/or1k.c b/gcc/config/or1k/or1k.c
index 54c9e804ea5..d90826b75ca 100644
--- a/gcc/config/or1k/or1k.c
+++ b/gcc/config/or1k/or1k.c
@@ -1226,6 +1226,17 @@ or1k_print_operand (FILE *file, rtx x, int code)
 	output_operand_lossage ("invalid %%H value");
       break;
 
+    case 'd':
+      if (REG_P (x))
+	  if (GET_MODE (x) == DFmode || GET_MODE (x) == DImode)
+	    fprintf (file, "%s,%s", reg_names[REGNO (operand)],
+				    reg_names[REGNO (operand) + 1]);
+	  else
+	    fprintf (file, "%s", reg_names[REGNO (operand)]);
+      else
+	output_operand_lossage ("invalid %%d value");
+      break;
+
     case 'h':
       print_reloc (file, x, 0, RKIND_HI);
       break;
@@ -1435,21 +1446,42 @@ void
 or1k_expand_compare (rtx *operands)
 {
   rtx sr_f = gen_rtx_REG (BImode, SR_F_REGNUM);
+  rtx_code cmp_code = GET_CODE (operands[0]);
+  bool flag_check_ne = true;
 
   /* The RTL may receive an immediate in argument 1 of the compare, this is not
      supported unless we have l.sf*i instructions, force them into registers.  */
   if (!TARGET_SFIMM)
     XEXP (operands[0], 1) = force_reg (SImode, XEXP (operands[0], 1));
 
+  /* Normalize comparison operators to ones OpenRISC support.  */
+  switch (cmp_code)
+    {
+      case LTGT:
+	cmp_code = UNEQ;
+	flag_check_ne = false;
+	break;
+
+      case ORDERED:
+	cmp_code = UNORDERED;
+	flag_check_ne = false;
+	break;
+
+      default:
+	break;
+    }
+
   /* Emit the given comparison into the Flag bit.  */
   PUT_MODE (operands[0], BImode);
+  PUT_CODE (operands[0], cmp_code);
   emit_insn (gen_rtx_SET (sr_f, operands[0]));
 
   /* Adjust the operands for use in the caller.  */
-  operands[0] = gen_rtx_NE (VOIDmode, sr_f, const0_rtx);
+  operands[0] = flag_check_ne ? gen_rtx_NE (VOIDmode, sr_f, const0_rtx)
+			      : gen_rtx_EQ (VOIDmode, sr_f, const0_rtx);
   operands[1] = sr_f;
   operands[2] = const0_rtx;
-}
+ }
 
 /* Expand the patterns "call", "sibcall", "call_value" and "sibcall_value".
    Expands a function call where argument RETVAL is an optional RTX providing
diff --git a/gcc/config/or1k/or1k.h b/gcc/config/or1k/or1k.h
index 6dda230f217..7588c187e5f 100644
--- a/gcc/config/or1k/or1k.h
+++ b/gcc/config/or1k/or1k.h
@@ -189,6 +189,7 @@ enum reg_class
 {
   NO_REGS,
   SIBCALL_REGS,
+  DOUBLE_REGS,
   GENERAL_REGS,
   FLAG_REGS,
   ALL_REGS,
@@ -200,6 +201,7 @@ enum reg_class
 #define REG_CLASS_NAMES {	\
   "NO_REGS", 			\
   "SIBCALL_REGS",		\
+  "DOUBLE_REGS",		\
   "GENERAL_REGS",		\
   "FLAG_REGS",			\
   "ALL_REGS" }
@@ -212,6 +214,7 @@ enum reg_class
 #define REG_CLASS_CONTENTS      \
 { { 0x00000000, 0x00000000 },	\
   { SIBCALL_REGS_MASK,   0 },	\
+  { 0x7ffffefe, 0x00000000 },	\
   { 0xffffffff, 0x00000003 },	\
   { 0x00000000, 0x00000004 },	\
   { 0xffffffff, 0x00000007 }	\
diff --git a/gcc/config/or1k/or1k.md b/gcc/config/or1k/or1k.md
index bbad593db40..728ef96b99c 100644
--- a/gcc/config/or1k/or1k.md
+++ b/gcc/config/or1k/or1k.md
@@ -60,7 +60,7 @@
 (define_attr "length" "" (const_int 4))
 
 (define_attr "type"
-  "alu,st,ld,control,multi"
+  "alu,st,ld,control,multi,fpu"
   (const_string "alu"))
 
 (define_attr "insn_support" "class1,sext,sfimm,shftimm,ror,rori" (const_string "class1"))
@@ -97,6 +97,10 @@
 (define_insn_reservation "control" 1
   (eq_attr "type" "control")
   "cpu")
+(define_insn_reservation "fpu" 2
+  (eq_attr "type" "fpu")
+  "cpu")
+
 
 ; Define delay slots for any branch
 (define_delay (eq_attr "type" "control")
@@ -159,6 +163,47 @@
   ""
   "l.sub\t%0, %r1, %2")
 
+;; -------------------------------------------------------------------------
+;; Floating Point Arithmetic instructions
+;; -------------------------------------------------------------------------
+
+;; Mode iterator for single/double float
+(define_mode_iterator F [(SF "TARGET_HARD_FLOAT")
+			 (DF "TARGET_DOUBLE_FLOAT")])
+(define_mode_attr f [(SF "s") (DF "d")])
+(define_mode_attr fr [(SF "r") (DF "d")])
+(define_mode_attr fi [(SF "si") (DF "di")])
+(define_mode_attr FI [(SF "SI") (DF "DI")])
+
+;; Basic arithmetic instructions
+(define_code_iterator FOP [plus minus mult div])
+(define_code_attr fop [(plus "add") (minus "sub") (mult "mul") (div "div")])
+
+(define_insn "<fop><F:mode>3"
+  [(set (match_operand:F 0 "register_operand" "=<fr>")
+	(FOP:F (match_operand:F 1 "register_operand" "<fr>")
+	       (match_operand:F 2 "register_operand" "<fr>")))]
+  "TARGET_HARD_FLOAT"
+  "lf.<fop>.<f>\t%d0, %d1, %d2"
+  [(set_attr "type" "fpu")])
+
+;; Basic float<->int conversion
+(define_insn "float<fi><F:mode>2"
+  [(set (match_operand:F 0 "register_operand" "=<fr>")
+	(float:F
+	    (match_operand:<FI> 1 "register_operand" "<fr>")))]
+  "TARGET_HARD_FLOAT"
+  "lf.itof.<f>\t%d0, %d1"
+  [(set_attr "type" "fpu")])
+
+(define_insn "fix_trunc<F:mode><fi>2"
+  [(set (match_operand:<FI> 0 "register_operand" "=<fr>")
+	(fix:<FI>
+	    (match_operand:F 1 "register_operand" "<fr>")))]
+  "TARGET_HARD_FLOAT"
+  "lf.ftoi.<f>\t%d0, %d1"
+  [(set_attr "type" "fpu")])
+
 ;; -------------------------------------------------------------------------
 ;; Logical operators
 ;; -------------------------------------------------------------------------
@@ -380,7 +425,7 @@
 (define_code_iterator intcmpcc [ne eq lt ltu gt gtu ge le geu leu])
 (define_code_attr insn [(ne "ne") (eq "eq") (lt "lts") (ltu "ltu")
 			(gt "gts") (gtu "gtu") (ge "ges") (le "les")
-			(geu "geu") (leu "leu") ])
+			(geu "geu") (leu "leu")])
 
 (define_insn "*sf_insn"
   [(set (reg:BI SR_F_REGNUM)
@@ -392,6 +437,36 @@
    l.sf<insn>i\t%r0, %1"
   [(set_attr "insn_support" "*,sfimm")])
 
+;; Support FP comparisons too
+
+;; The OpenRISC FPU supports these comparisons:
+;;
+;;    lf.sfeq.{d,s} - equality, r r, double or single precision
+;;    lf.sfge.{d,s} - greater than or equal, r r, double or single precision
+;;    lf.sfgt.{d,s} - greater than, r r, double or single precision
+;;    lf.sfle.{d,s} - less than or equal, r r, double or single precision
+;;    lf.sflt.{d,s} - less than, r r, double or single precision
+;;    lf.sfne.{d,s} - not equal, r r, double or single precision
+;;
+;; Double precision is only supported on some hardware.  Only register/register
+;; comparisons are supported.  All comparisons are signed.
+
+(define_code_iterator fpcmpcc [ne eq lt gt ge le uneq unle unlt ungt unge
+			       unordered])
+(define_code_attr fpcmpinsn [(ne "ne") (eq "eq") (lt "lt") (gt "gt") (ge "ge")
+			     (le "le") (uneq "ueq") (unle "ule") (unlt "ult")
+			     (ungt "ugt") (unge "uge") (unordered "un")])
+
+
+(define_insn "*sf_fp_insn"
+  [(set (reg:BI SR_F_REGNUM)
+	(fpcmpcc:BI (match_operand:F 0 "register_operand" "<fr>")
+		    (match_operand:F 1 "register_operand" "<fr>")))]
+  "TARGET_HARD_FLOAT"
+  "lf.sf<fpcmpinsn>.<f>\t%d0, %d1"
+  [(set_attr "type" "fpu")])
+
+
 ;; -------------------------------------------------------------------------
 ;; Conditional Store instructions
 ;; -------------------------------------------------------------------------
@@ -412,6 +487,23 @@
   DONE;
 })
 
+;; Support FP cstores too
+(define_expand "cstore<F:mode>4"
+  [(set (match_operand:SI 0 "register_operand" "")
+	(if_then_else:F
+	  (match_operator 1 "fp_comparison_operator"
+	    [(match_operand:F 2 "register_operand" "")
+	     (match_operand:F 3 "register_operand" "")])
+	  (match_dup 0)
+	  (const_int 0)))]
+  "TARGET_HARD_FLOAT"
+{
+  or1k_expand_compare (operands + 1);
+  PUT_MODE (operands[1], SImode);
+  emit_insn (gen_rtx_SET (operands[0], operands[1]));
+  DONE;
+})
+
 ;; Being able to "copy" SR_F to a general register is helpful for
 ;; the atomic insns, wherein the usual usage is to test the success
 ;; of the compare-and-swap.  Representing the operation in this way,
@@ -505,6 +597,21 @@
   or1k_expand_compare (operands);
 })
 
+;; Support FP branching
+
+(define_expand "cbranch<F:mode>4"
+  [(set (pc)
+	(if_then_else
+	  (match_operator 0 "fp_comparison_operator"
+	    [(match_operand:F 1 "register_operand" "")
+	     (match_operand:F 2 "register_operand" "")])
+	  (label_ref (match_operand 3 "" ""))
+	  (pc)))]
+  "TARGET_HARD_FLOAT"
+{
+  or1k_expand_compare (operands);
+})
+
 (define_insn "*cbranch"
   [(set (pc)
 	(if_then_else
diff --git a/gcc/config/or1k/or1k.opt b/gcc/config/or1k/or1k.opt
index c2f64c5dd45..15085fafa3f 100644
--- a/gcc/config/or1k/or1k.opt
+++ b/gcc/config/or1k/or1k.opt
@@ -41,6 +41,28 @@ Target RejectNegative Mask(SOFT_MUL).
 Enable generation of binaries which use functions from libgcc to perform
 multiply operations. The default is -mhard-mul.
 
+msoft-float
+Target RejectNegative InverseMask(HARD_FLOAT)
+Enable generation of binaries which use functions from libgcc to perform
+floating point operations.  This is the default; use -mhard-float to override.
+
+mhard-float
+Target RejectNegative Mask(HARD_FLOAT)
+Enable generation of hardware floating point instructions. The default is
+-msoft-float.
+
+mdouble-float
+Target Mask(DOUBLE_FLOAT)
+When -mhard-float is selected, enables generation of double-precision floating
+point instructions.  By default functions from libgcc are used to perform
+double-precision floating point operations.
+
+munordered-float
+Target RejectNegative Mask(FP_UNORDERED)
+When -mhard-float is selected, enables generation of unordered floating point
+compare and set flag (lf.sfun*) instructions.  By default functions from libgcc
+are used to perform unordered floating point compare and set flag operations.
+
 mcmov
 Target RejectNegative Mask(CMOV)
 Enable generation of conditional move (l.cmov) instructions.  By default the
diff --git a/gcc/config/or1k/predicates.md b/gcc/config/or1k/predicates.md
index b895f1b4228..a1231dbad33 100644
--- a/gcc/config/or1k/predicates.md
+++ b/gcc/config/or1k/predicates.md
@@ -83,6 +83,11 @@
 (define_predicate "equality_comparison_operator"
   (match_code "ne,eq"))
 
+(define_predicate "fp_comparison_operator"
+  (if_then_else (match_test "TARGET_FP_UNORDERED")
+    (match_operand 0 "comparison_operator")
+    (match_operand 0 "ordered_comparison_operator")))
+
 ;; Borrowed from rs6000
 ;  Return true if the operand is in volatile memory.  Note that during the
 ;; RTL generation phase, memory_operand does not return TRUE for volatile
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1f1f73672bd..379e4a9b731 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1033,6 +1033,7 @@ Objective-C and Objective-C++ Dialects}.
 @emph{OpenRISC Options}
 @gccoptlist{-mboard=@var{name}  -mnewlib  -mhard-mul  -mhard-div @gol
 -msoft-mul  -msoft-div @gol
+-msoft-float  -mhard-float  -mdouble-float -munordered-float @gol
 -mcmov  -mror  -mrori  -msext  -msfimm  -mshftimm}
 
 @emph{PDP-11 Options}
@@ -23649,6 +23650,26 @@ This default is hardware divide.
 Select software or hardware multiply (@code{l.mul}, @code{l.muli}) instructions.
 This default is hardware multiply.
 
+ at item -msoft-float
+ at itemx -mhard-float
+ at opindex msoft-float
+ at opindex mhard-float
+Select software or hardware for floating point operations.
+The default is software.
+
+ at item -mdouble-float
+ at opindex mdouble-float
+When @option{-mhard-float} is selected, enables generation of double-precision
+floating point instructions.  By default functions from @file{libgcc} are used
+to perform double-precision floating point operations.
+
+ at item -munordered-float
+ at opindex munordered-float
+When @option{-mhard-float} is selected, enables generation of unordered
+floating point compare and set flag (@code{lf.sfun*}) instructions.  By default
+functions from @file{libgcc} are used to perform unordered floating point
+compare and set flag operations.
+
 @item -mcmov
 @opindex mcmov
 Enable generation of conditional move (@code{l.cmov}) instructions.  By
-- 
2.21.0

[OpenRISC] [PATCH v2 5/5] or1k: only force reg for immediates

[Stafford Horne]

The force_reg in or1k_expand_compare is hard coded for SImode, which is fine as
this used to only be used on SI expands.  However, with FP support this will
cause issues.  In general we should only force the right hand operand to a
register if its an immediate.  This patch adds an condition to check for that.

gcc/ChangeLog:

	* config/or1k/or1k.c (or1k_expand_compare): Check for int before
	force_reg.
---
Changes since v1:
 - none

 gcc/config/or1k/or1k.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/gcc/config/or1k/or1k.c b/gcc/config/or1k/or1k.c
index d90826b75ca..e4aff83cec7 100644
--- a/gcc/config/or1k/or1k.c
+++ b/gcc/config/or1k/or1k.c
@@ -1446,13 +1446,15 @@ void
 or1k_expand_compare (rtx *operands)
 {
   rtx sr_f = gen_rtx_REG (BImode, SR_F_REGNUM);
+  rtx righthand_op = XEXP (operands[0], 1);
   rtx_code cmp_code = GET_CODE (operands[0]);
   bool flag_check_ne = true;
 
-  /* The RTL may receive an immediate in argument 1 of the compare, this is not
-     supported unless we have l.sf*i instructions, force them into registers.  */
-  if (!TARGET_SFIMM)
-    XEXP (operands[0], 1) = force_reg (SImode, XEXP (operands[0], 1));
+  /* Integer RTL may receive an immediate in argument 1 of the compare, this is
+     not supported unless we have l.sf*i instructions, force them into
+     registers.  */
+  if (!TARGET_SFIMM && CONST_INT_P (righthand_op))
+    XEXP (operands[0], 1) = force_reg (SImode, righthand_op);
 
   /* Normalize comparison operators to ones OpenRISC support.  */
   switch (cmp_code)
-- 
2.21.0

[OpenRISC] [PATCH v2 3/5] or1k: Add mrori option, fix option docs

[Segher Boessenkool]

On Wed, Jul 03, 2019 at 12:33:49PM +0900, Stafford Horne wrote:
> @@ -179,11 +183,11 @@
>    [(set (match_operand:SI 0 "register_operand" "=r,r")
>  	(rotatert:SI (match_operand:SI 1 "register_operand"  "r,r")
>  		  (match_operand:SI 2 "reg_or_u6_operand" "r,n")))]
> -  "TARGET_ROR"
> +  "TARGET_ROR || TARGET_RORI"
>    "@
>     l.ror\t%0, %1, %2
>     l.rori\t%0, %1, %2"
> -  [(set_attr "insn_support" "*,shftimm")])
> +  [(set_attr "insn_support" "ror,rori")])

Does this work?  If you use -mno-ror -mrori?  It will then allow generating
a reg for the second operand, and ICE later on, as far as I can see?


Segher

[OpenRISC] [PATCH v2 4/5] or1k: Initial support for FPU

[Segher Boessenkool]

Hi Stafford,

On Wed, Jul 03, 2019 at 12:33:50PM +0900, Stafford Horne wrote:
> +    case 'd':
> +      if (REG_P (x))
> +	  if (GET_MODE (x) == DFmode || GET_MODE (x) == DImode)
> +	    fprintf (file, "%s,%s", reg_names[REGNO (operand)],
> +				    reg_names[REGNO (operand) + 1]);
> +	  else
> +	    fprintf (file, "%s", reg_names[REGNO (operand)]);
> +      else

The coding conventions says to use braces around nested conditionals.

> @@ -212,6 +214,7 @@ enum reg_class
>  #define REG_CLASS_CONTENTS      \
>  { { 0x00000000, 0x00000000 },	\
>    { SIBCALL_REGS_MASK,   0 },	\
> +  { 0x7ffffefe, 0x00000000 },	\

Above you said r0, r30, r31 are excluded, but this is r0, r8, r30, or
in GCC register numbers, 0, 8, and 31?  You probably should mention r8
somewhere (it's because it is the last arg, this avoid problems, I guess?),
and the 30/31 thing is confused some way.  Maybe it is all just that one
documentation line :-)

> +;  d - double pair base registers (excludes r0, r30 and r31 which overflow)


Segher

[OpenRISC] [PATCH v2 4/5] or1k: Initial support for FPU

[Richard Henderson]

On 7/3/19 5:43 PM, Segher Boessenkool wrote:
>> @@ -212,6 +214,7 @@ enum reg_class
>>  #define REG_CLASS_CONTENTS      \
>>  { { 0x00000000, 0x00000000 },	\
>>    { SIBCALL_REGS_MASK,   0 },	\
>> +  { 0x7ffffefe, 0x00000000 },	\
> 
> Above you said r0, r30, r31 are excluded, but this is r0, r8, r30, or
> in GCC register numbers, 0, 8, and 31?  You probably should mention r8
> somewhere (it's because it is the last arg, this avoid problems, I guess?),
> and the 30/31 thing is confused some way.  Maybe it is all just that one
> documentation line :-)

... and if r8 is excluded because of arguments, I suspect that this is the
wrong fix, as there's nothing inherently wrong with r7:r8 or r8:r9 as a pair,
at least that I can see.

Perhaps function_arg and/or function_arg_advance is the right place for a fix?
The calling convention says that 64-bit arguments are not split across
registers+stack, so you already shouldn't have seen (r8, [sp+0]) as a pair.


r~

[OpenRISC] [PATCH v2 3/5] or1k: Add mrori option, fix option docs

[Stafford Horne]

On Wed, Jul 03, 2019 at 09:49:02AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 03, 2019 at 12:33:49PM +0900, Stafford Horne wrote:
> > @@ -179,11 +183,11 @@
> >    [(set (match_operand:SI 0 "register_operand" "=r,r")
> >  	(rotatert:SI (match_operand:SI 1 "register_operand"  "r,r")
> >  		  (match_operand:SI 2 "reg_or_u6_operand" "r,n")))]
> > -  "TARGET_ROR"
> > +  "TARGET_ROR || TARGET_RORI"
> >    "@
> >     l.ror\t%0, %1, %2
> >     l.rori\t%0, %1, %2"
> > -  [(set_attr "insn_support" "*,shftimm")])
> > +  [(set_attr "insn_support" "ror,rori")])
> 
> Does this work?  If you use -mno-ror -mrori?  It will then allow generating
> a reg for the second operand, and ICE later on, as far as I can see?

It does seem to work.  Why would it produce an internal compiler error?

One thing I have is RegectNegative on mror and mrori, so -mno-ror will not be
allowed and cause an error.

Example: 

    $ cat ./gcc/testsuite/gcc.target/or1k/ror-4.c

	unsigned int rotate6 (unsigned int a) {
	  return ( a >> 6 ) | ( a << ( 32 - 6 ) );
	}

# With rori, direct immediate.

    $ or1k-elf-gcc -O2 -c -mrori ./gcc/testsuite/gcc.target/or1k/ror-4.c 
    $ or1k-elf-objdump -d ror-4.o 

	ror-4.o:     file format elf32-or1k

	Disassembly of section .text:

	00000000 <rotate6>:
	   0:   44 00 48 00     l.jr r9
	   4:   b9 63 00 c6     l.rori r11,r3,0x6

# With ror, loading immediate to temporary register first.

    $ or1k-elf-gcc -O2 -c -mror ./gcc/testsuite/gcc.target/or1k/ror-4.c 
    $ or1k-elf-objdump -d ror-4.o 

	ror-4.o:     file format elf32-or1k

	Disassembly of section .text:

	00000000 <rotate6>:
	   0:   aa 20 00 06     l.ori r17,r0,0x6
	   4:   44 00 48 00     l.jr r9
	   8:   e1 63 88 c8     l.ror r11,r3,r17

-Stafford

[OpenRISC] [PATCH v2 4/5] or1k: Initial support for FPU

[Stafford Horne]

On Wed, Jul 03, 2019 at 10:43:01AM -0500, Segher Boessenkool wrote:
> Hi Stafford,
> 
> On Wed, Jul 03, 2019 at 12:33:50PM +0900, Stafford Horne wrote:
> > +    case 'd':
> > +      if (REG_P (x))
> > +	  if (GET_MODE (x) == DFmode || GET_MODE (x) == DImode)
> > +	    fprintf (file, "%s,%s", reg_names[REGNO (operand)],
> > +				    reg_names[REGNO (operand) + 1]);
> > +	  else
> > +	    fprintf (file, "%s", reg_names[REGNO (operand)]);
> > +      else
> 
> The coding conventions says to use braces around nested conditionals.

Right I will fix that.  Interestingly the indentation is correct just missing
the braces.
 
> > @@ -212,6 +214,7 @@ enum reg_class
> >  #define REG_CLASS_CONTENTS      \
> >  { { 0x00000000, 0x00000000 },	\
> >    { SIBCALL_REGS_MASK,   0 },	\
> > +  { 0x7ffffefe, 0x00000000 },	\
> 
> Above you said r0, r30, r31 are excluded, but this is r0, r8, r30, or
> in GCC register numbers, 0, 8, and 31?  You probably should mention r8
> somewhere (it's because it is the last arg, this avoid problems, I guess?),
> and the 30/31 thing is confused some way.  Maybe it is all just that one
> documentation line :-)
>
> > +;  d - double pair base registers (excludes r0, r30 and r31 which overflow)

Hmm, maybe I messed up the mask.  It should be r0, r30 and r31.  Register pairs
can be a base register (rX) with a +1 or +2 offset second register.

Registers not allowed
  - r0, because its reserved for hardwired zero and doesn't work as a double
    zero when paired with a general register.
  - r31, because it cant pair with r32 or r33 (those are overflows)
  - r30, because it cant work when paried with r32 (its an overflow), it would
    work with r31, but GCC will not generate that pair anyway.

-Stafford

[OpenRISC] [PATCH v2 4/5] or1k: Initial support for FPU

[Stafford Horne]

On Wed, Jul 03, 2019 at 09:09:51PM +0200, Richard Henderson wrote:
> On 7/3/19 5:43 PM, Segher Boessenkool wrote:
> >> @@ -212,6 +214,7 @@ enum reg_class
> >>  #define REG_CLASS_CONTENTS      \
> >>  { { 0x00000000, 0x00000000 },	\
> >>    { SIBCALL_REGS_MASK,   0 },	\
> >> +  { 0x7ffffefe, 0x00000000 },	\
> > 
> > Above you said r0, r30, r31 are excluded, but this is r0, r8, r30, or
> > in GCC register numbers, 0, 8, and 31?  You probably should mention r8
> > somewhere (it's because it is the last arg, this avoid problems, I guess?),
> > and the 30/31 thing is confused some way.  Maybe it is all just that one
> > documentation line :-)
> 
> ... and if r8 is excluded because of arguments, I suspect that this is the
> wrong fix, as there's nothing inherently wrong with r7:r8 or r8:r9 as a pair,
> at least that I can see.
> 
> Perhaps function_arg and/or function_arg_advance is the right place for a fix?
> The calling convention says that 64-bit arguments are not split across
> registers+stack, so you already shouldn't have seen (r8, [sp+0]) as a pair.

I will double check, the mask may be wrong.  It should not matter about the
function args.

I didn't see any issue that caused me to add r8.  So I may have just masked thw
rong bit thinking it's r31.  Is there something worng with what I did?

The mask is 0x7ffffefe, and names should corresbond to this name list?

#define REGISTER_NAMES {
  "r0",   "r1",   "r2",   "r3",   "r4",   "r5",   "r6",   "r7",  # 7e, excl r0
  "r8",   "r9",   "r10",  "r11",  "r12",  "r13",  "r14",  "r15", # ff, excl none
  "r17",  "r19",  "r21",  "r23",  "r25",  "r27",  "r29",  "r31", # fe, excl r31
  "r16",  "r18",  "r20",  "r22",  "r24",  "r26",  "r28",  "r30", # fe, excl r30
  "?ap",  "?fp",  "?sr_f" }

Do I have it backwards?  With an endian issue?

-Stafford

[OpenRISC] [PATCH v2 3/5] or1k: Add mrori option, fix option docs

[Segher Boessenkool]

On Thu, Jul 04, 2019 at 06:49:17AM +0900, Stafford Horne wrote:
> On Wed, Jul 03, 2019 at 09:49:02AM -0500, Segher Boessenkool wrote:
> > On Wed, Jul 03, 2019 at 12:33:49PM +0900, Stafford Horne wrote:
> > > @@ -179,11 +183,11 @@
> > >    [(set (match_operand:SI 0 "register_operand" "=r,r")
> > >  	(rotatert:SI (match_operand:SI 1 "register_operand"  "r,r")
> > >  		  (match_operand:SI 2 "reg_or_u6_operand" "r,n")))]
> > > -  "TARGET_ROR"
> > > +  "TARGET_ROR || TARGET_RORI"
> > >    "@
> > >     l.ror\t%0, %1, %2
> > >     l.rori\t%0, %1, %2"
> > > -  [(set_attr "insn_support" "*,shftimm")])
> > > +  [(set_attr "insn_support" "ror,rori")])
> > 
> > Does this work?  If you use -mno-ror -mrori?  It will then allow generating
> > a reg for the second operand, and ICE later on, as far as I can see?
> 
> It does seem to work.  Why would it produce an internal compiler error?
> 
> One thing I have is RegectNegative on mror and mrori, so -mno-ror will not be
> allowed and cause an error.

But both options are off by default, and neither is enabled or disabled
based on the setting of the other.

> Example: 
> 
>     $ cat ./gcc/testsuite/gcc.target/or1k/ror-4.c
> 
> 	unsigned int rotate6 (unsigned int a) {
> 	  return ( a >> 6 ) | ( a << ( 32 - 6 ) );
> 	}

That's a fixed distance rotate.  My question is will it work if the
distance is a variable.  The other direction should work fine, agreed.

So, does ror-[12].c work with -mrori and no -mror?  The predicates say
this insn pattern is just fine in that case, but the constraints will
disagree.


Segher

[OpenRISC] [PATCH v2 4/5] or1k: Initial support for FPU

[Segher Boessenkool]

On Thu, Jul 04, 2019 at 07:19:56AM +0900, Stafford Horne wrote:
> On Wed, Jul 03, 2019 at 09:09:51PM +0200, Richard Henderson wrote:
> > On 7/3/19 5:43 PM, Segher Boessenkool wrote:
> > >> @@ -212,6 +214,7 @@ enum reg_class
> > >>  #define REG_CLASS_CONTENTS      \
> > >>  { { 0x00000000, 0x00000000 },	\
> > >>    { SIBCALL_REGS_MASK,   0 },	\
> > >> +  { 0x7ffffefe, 0x00000000 },	\
> > > 
> > > Above you said r0, r30, r31 are excluded, but this is r0, r8, r30, or
> > > in GCC register numbers, 0, 8, and 31?  You probably should mention r8
> > > somewhere (it's because it is the last arg, this avoid problems, I guess?),
> > > and the 30/31 thing is confused some way.  Maybe it is all just that one
> > > documentation line :-)
> > 
> > ... and if r8 is excluded because of arguments, I suspect that this is the
> > wrong fix, as there's nothing inherently wrong with r7:r8 or r8:r9 as a pair,
> > at least that I can see.
> > 
> > Perhaps function_arg and/or function_arg_advance is the right place for a fix?
> > The calling convention says that 64-bit arguments are not split across
> > registers+stack, so you already shouldn't have seen (r8, [sp+0]) as a pair.
> 
> I will double check, the mask may be wrong.  It should not matter about the
> function args.
> 
> I didn't see any issue that caused me to add r8.  So I may have just masked thw
> rong bit thinking it's r31.  Is there something worng with what I did?
> 
> The mask is 0x7ffffefe, and names should corresbond to this name list?
> 
> #define REGISTER_NAMES {
>   "r0",   "r1",   "r2",   "r3",   "r4",   "r5",   "r6",   "r7",  # 7e, excl r0
>   "r8",   "r9",   "r10",  "r11",  "r12",  "r13",  "r14",  "r15", # ff, excl none
>   "r17",  "r19",  "r21",  "r23",  "r25",  "r27",  "r29",  "r31", # fe, excl r31
>   "r16",  "r18",  "r20",  "r22",  "r24",  "r26",  "r28",  "r30", # fe, excl r30
>   "?ap",  "?fp",  "?sr_f" }
> 
> Do I have it backwards?  With an endian issue?

Yes :-)  0x00000001 is reg 0 (r0), 0x80000000 is reg 31 (r30).


Segher

[OpenRISC] [PATCH v2 3/5] or1k: Add mrori option, fix option docs

[Stafford Horne]

On Wed, Jul 03, 2019 at 05:26:58PM -0500, Segher Boessenkool wrote:
> On Thu, Jul 04, 2019 at 06:49:17AM +0900, Stafford Horne wrote:
> > On Wed, Jul 03, 2019 at 09:49:02AM -0500, Segher Boessenkool wrote:
> > > On Wed, Jul 03, 2019 at 12:33:49PM +0900, Stafford Horne wrote:
> > > > @@ -179,11 +183,11 @@
> > > >    [(set (match_operand:SI 0 "register_operand" "=r,r")
> > > >  	(rotatert:SI (match_operand:SI 1 "register_operand"  "r,r")
> > > >  		  (match_operand:SI 2 "reg_or_u6_operand" "r,n")))]
> > > > -  "TARGET_ROR"
> > > > +  "TARGET_ROR || TARGET_RORI"
> > > >    "@
> > > >     l.ror\t%0, %1, %2
> > > >     l.rori\t%0, %1, %2"
> > > > -  [(set_attr "insn_support" "*,shftimm")])
> > > > +  [(set_attr "insn_support" "ror,rori")])
> > > 
> > > Does this work?  If you use -mno-ror -mrori?  It will then allow generating
> > > a reg for the second operand, and ICE later on, as far as I can see?
> > 
> > It does seem to work.  Why would it produce an internal compiler error?
> > 
> > One thing I have is RegectNegative on mror and mrori, so -mno-ror will not be
> > allowed and cause an error.
> 
> But both options are off by default, and neither is enabled or disabled
> based on the setting of the other.
> 
> > Example: 
> > 
> >     $ cat ./gcc/testsuite/gcc.target/or1k/ror-4.c
> > 
> > 	unsigned int rotate6 (unsigned int a) {
> > 	  return ( a >> 6 ) | ( a << ( 32 - 6 ) );
> > 	}
> 
> That's a fixed distance rotate.  My question is will it work if the
> distance is a variable.  The other direction should work fine, agreed.
> 
> So, does ror-[12].c work with -mrori and no -mror?  The predicates say
> this insn pattern is just fine in that case, but the constraints will
> disagree.

OK, yes I see it now.  Sorry I mis-understood what you meant by second argument.
I will fix.  It's probably going to be easiest to split this to 2 instructions.

-Stafford