public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Meissner <meissner@linux.ibm.com>
To: Michael Meissner <meissner@linux.ibm.com>,
	gcc-patches@gcc.gnu.org,
	       Segher Boessenkool <segher@kernel.crashing.org>,
	       David Edelsohn <dje.gcc@gmail.com>
Subject: [PATCH] V11 patch #5 of 15, Optimize vec_extract of a vector in memory with a PC-relative address
Date: Sat, 21 Dec 2019 00:00:00 -0000	[thread overview]
Message-ID: <20191220235553.GE28993@ibm-toto.the-meissners.org> (raw)
In-Reply-To: <20191220231507.GA18386@ibm-toto.the-meissners.org>

This patch recognizes when we are doing the optimization of vector extract with
a constant element number when the vector is in memory and the vector's address
is PC-relative, to directly re-form the address using a PC-relative load,
instead of loading the address into a temporary register, and then doing an
indirect load.

I have bootstrapped a compiler on a little endian power8 machine and ran the
testsuite with no regressions.  Can I check this into the trunk?

2019-12-20  Michael Meissner  <meissner@linux.ibm.com>

	* config/rs6000/rs6000.c (rs6000_reg_to_addr_mask): New helper
	function to identify the address mask of a hard register.
	(rs6000_adjust_vec_address): If we have a PC-relative address and
	a constant vector element number, fold the element number into the
	PC-relative address.

Index: gcc/config/rs6000/rs6000.c
===================================================================
--- gcc/config/rs6000/rs6000.c	(revision 279597)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -6722,6 +6722,30 @@ rs6000_expand_vector_extract (rtx target
     }
 }
 
+/* Helper function to return an address mask based on a physical register.  */
+
+static addr_mask_type
+rs6000_reg_to_addr_mask (rtx reg, machine_mode mode)
+{
+  unsigned int r = reg_or_subregno (reg);
+  addr_mask_type addr_mask;
+
+  gcc_assert (HARD_REGISTER_NUM_P (r));
+  if (INT_REGNO_P (r))
+    addr_mask = reg_addr[mode].addr_mask[RELOAD_REG_GPR];
+
+  else if (FP_REGNO_P (r))
+    addr_mask = reg_addr[mode].addr_mask[RELOAD_REG_FPR];
+
+  else if (ALTIVEC_REGNO_P (r))
+    addr_mask = reg_addr[mode].addr_mask[RELOAD_REG_VMX];
+
+  else
+    gcc_unreachable ();
+
+  return addr_mask;
+}
+
 /* Adjust a memory address (MEM) of a vector type to point to a scalar field
    within the vector (ELEMENT) with a mode (SCALAR_MODE).  Use a base register
    temporary (BASE_TMP) to fixup the address.  Return the new memory address
@@ -6854,6 +6878,51 @@ rs6000_adjust_vec_address (rtx scalar_re
 	}
     }
 
+  /* For references to local static variables, try to fold a constant offset
+     into the address.  */
+  else if (pcrel_local_address (addr, Pmode) && CONST_INT_P (element_offset))
+    {
+      if (GET_CODE (addr) == CONST)
+	addr = XEXP (addr, 0);
+
+      if (GET_CODE (addr) == PLUS)
+	{
+	  rtx op0 = XEXP (addr, 0);
+	  rtx op1 = XEXP (addr, 1);
+	  if (CONST_INT_P (op1))
+	    {
+	      HOST_WIDE_INT offset
+		= INTVAL (XEXP (addr, 1)) + INTVAL (element_offset);
+
+	      if (offset == 0)
+		new_addr = op0;
+
+	      else if (SIGNED_INTEGER_34BIT_P (offset))
+		{
+		  rtx plus = gen_rtx_PLUS (Pmode, op0, GEN_INT (offset));
+		  new_addr = gen_rtx_CONST (Pmode, plus);
+		}
+
+	      else
+		{
+		  emit_move_insn (base_tmp, addr);
+		  new_addr = gen_rtx_PLUS (Pmode, base_tmp, element_offset);
+		}
+	    }
+	  else
+	    {
+	      emit_move_insn (base_tmp, addr);
+	      new_addr = gen_rtx_PLUS (Pmode, base_tmp, element_offset);
+	    }
+	}
+
+      else
+	{
+	  rtx plus = gen_rtx_PLUS (Pmode, addr, element_offset);
+	  new_addr = gen_rtx_CONST (Pmode, plus);
+	}
+    }
+
   else
     {
       /* Make sure base_tmp is not the same as element_offset.  This can happen
@@ -6869,21 +6938,8 @@ rs6000_adjust_vec_address (rtx scalar_re
   if (GET_CODE (new_addr) == PLUS)
     {
       rtx op1 = XEXP (new_addr, 1);
-      addr_mask_type addr_mask;
-      unsigned int scalar_regno = reg_or_subregno (scalar_reg);
-
-      gcc_assert (HARD_REGISTER_NUM_P (scalar_regno));
-      if (INT_REGNO_P (scalar_regno))
-	addr_mask = reg_addr[scalar_mode].addr_mask[RELOAD_REG_GPR];
-
-      else if (FP_REGNO_P (scalar_regno))
-	addr_mask = reg_addr[scalar_mode].addr_mask[RELOAD_REG_FPR];
-
-      else if (ALTIVEC_REGNO_P (scalar_regno))
-	addr_mask = reg_addr[scalar_mode].addr_mask[RELOAD_REG_VMX];
-
-      else
-	gcc_unreachable ();
+      addr_mask_type addr_mask
+	= rs6000_reg_to_addr_mask (scalar_reg, scalar_mode);
 
       if (REG_P (op1) || SUBREG_P (op1))
 	valid_addr_p = (addr_mask & RELOAD_REG_INDEXED) != 0;
@@ -6891,9 +6947,21 @@ rs6000_adjust_vec_address (rtx scalar_re
 	valid_addr_p = (addr_mask & RELOAD_REG_OFFSET) != 0;
     }
 
+  /* An address that is a single register is always valid for either indexed or
+     offsettable loads.  */
   else if (REG_P (new_addr) || SUBREG_P (new_addr))
     valid_addr_p = true;
 
+  /* If we have a PC-relative address, check if offsetable loads are
+     allowed.  */
+  else if (pcrel_local_address (new_addr, Pmode))
+    {
+      addr_mask_type addr_mask
+	= rs6000_reg_to_addr_mask (scalar_reg, scalar_mode);
+
+      valid_addr_p = (addr_mask & RELOAD_REG_OFFSET) != 0;
+    }
+
   else
     valid_addr_p = false;
 

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797

  parent reply	other threads:[~2019-12-20 23:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20 23:15 PowerPC -mcpu=future patches, V11 Michael Meissner
2019-12-20 23:28 ` [PATCH] V11 patch #1 of 15, Fix bug in vec_extract Michael Meissner
2019-12-22 14:06   ` Segher Boessenkool
2019-12-20 23:47 ` [PATCH] V11 patch #2 of 15, Use prefixed load for vector extract with large offset Michael Meissner
2019-12-22 17:24   ` Segher Boessenkool
2020-01-07  1:41     ` [PATCH, committed] " Michael Meissner
2019-12-20 23:49 ` [PATCH] V11 patch #3 of 15, Use 'Q' constraint for variable vector extract from memory Michael Meissner
2019-12-22 17:49   ` Segher Boessenkool
2020-01-07  1:43     ` [PATCH, committed] " Michael Meissner
2019-12-20 23:56 ` [PATCH] V11 patch #4 of 15, Update 'Q' constraint documentation Michael Meissner
2019-12-22 20:02   ` Segher Boessenkool
2020-01-07  1:45     ` [PATCH, committed] " Michael Meissner
2019-12-21  0:00 ` Michael Meissner [this message]
2019-12-25  6:41   ` [PATCH] V11 patch #5 of 15, Optimize vec_extract of a vector in memory with a PC-relative address Segher Boessenkool
2020-01-06 20:55     ` Michael Meissner
2020-01-06 21:01     ` Michael Meissner
2020-01-07  1:48     ` [PATCH, committed] " Michael Meissner
2019-12-21  0:03 ` [PATCH] V11 patch #6 of 15, Make -mpcrel the default for -mcpu=future on Linux 64-bit Michael Meissner
2019-12-21  0:06 ` [PATCH] V11 patch #7 of 15, Add new target_supports cases for -mcpu=future tests Michael Meissner
2019-12-21  0:11 ` [PATCH] V11 patch #8 of 15, Add new tests for using PADDI and PLI with -mcpu=future Michael Meissner
2019-12-21  0:12 ` [PATCH] V11 patch #9 of 15, Add test to validate generating prefixed memory when the offset is invalid for DS/DQ insns Michael Meissner
2019-12-21  0:22 ` [PATCH] V11 patch #10 of 15, Make sure we don't generate pre-modify prefixed insns with -mcpu=future Michael Meissner
2019-12-21  0:25 ` [PATCH] V11 patch #11 of 15, Add new tests for generating prefixed loads/stores on -mcpu=future with large offsets Michael Meissner
2019-12-21  0:25 ` [PATCH] V11 patch #12 of 15, Add new PC-relative tests for -mcpu=future Michael Meissner
2019-12-21  0:33 ` [PATCH] V11 patch #13 of 15, Add test for -mcpu=future -fstack-protect-strong with large stacks Michael Meissner
2019-12-21  1:23 ` [PATCH] V11 patch #14 of 15, Add tests for vec_extract from memory with PC-relative addrss Michael Meissner
2019-12-21  1:25 ` [PATCH] V11 patch #15 of 15, Add tests for -mcpu=future vec_extract from memory with a large offset Michael Meissner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191220235553.GE28993@ibm-toto.the-meissners.org \
    --to=meissner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).