public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@adacore.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: RFC: Add TARGET_EXPAND_COMPOUND_OPERATION
Date: Mon, 28 Jun 2010 10:44:00 -0000	[thread overview]
Message-ID: <201006281205.11210.ebotcazou@adacore.com> (raw)
In-Reply-To: <20100625195028.GA27734@intel.com>

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

> However, combiner never exposes this to x86 backend.  I added
> a TARGET_EXPAND_COMPOUND_OPERATION hook to allow x86 backend to
> optimize it.  For
>
> ---
> typedef struct
> {
>   unsigned char c1;
>   unsigned char c2;
>   unsigned char c3;
>   unsigned char c4;
> } foo_t;
>
> int
> foo (foo_t x)
> {
>    return x.c2 > 4;
> }

I think that disabling the canonicalization done by expand_compound_operation 
can disable certain forms of combining that are beneficial to x86 even for 
this kind of patterns.

The combiner already knows that it needs to re-create the compound forms when 
it is trying to simplify a comparison, see simplify_comparison.  The problem 
with your testcase is that make_compound_operation fails to do so.

Lightly tested patch attached.


	* combine.c (make_compound_operation) <SUBREG>: Do not return the
	result of force_to_mode if it partially re-expanded the compound.


-- 
Eric Botcazou

[-- Attachment #2: p.diff --]
[-- Type: text/x-diff, Size: 2228 bytes --]

Index: combine.c
===================================================================
--- combine.c	(revision 161470)
+++ combine.c	(working copy)
@@ -7277,22 +7277,21 @@ make_compound_operation (rtx x, enum rtx
       /* Call ourselves recursively on the inner expression.  If we are
 	 narrowing the object and it has a different RTL code from
 	 what it originally did, do this SUBREG as a force_to_mode.  */
-
-      tem = make_compound_operation (SUBREG_REG (x), in_code);
-
       {
-	rtx simplified = simplify_subreg (mode, tem, GET_MODE (SUBREG_REG (x)),
-					  SUBREG_BYTE (x));
+	rtx inner = SUBREG_REG (x), simplified;
+	
+	tem = make_compound_operation (inner, in_code);
 
+	simplified
+	  = simplify_subreg (mode, tem, GET_MODE (inner), SUBREG_BYTE (x));
 	if (simplified)
 	  tem = simplified;
 
-	if (GET_CODE (tem) != GET_CODE (SUBREG_REG (x))
-	    && GET_MODE_SIZE (mode) < GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))
+	if (GET_CODE (tem) != GET_CODE (inner)
+	    && GET_MODE_SIZE (mode) < GET_MODE_SIZE (GET_MODE (inner))
 	    && subreg_lowpart_p (x))
 	  {
-	    rtx newer = force_to_mode (tem, mode, ~(HOST_WIDE_INT) 0,
-				       0);
+	    rtx newer = force_to_mode (tem, mode, ~(HOST_WIDE_INT) 0, 0);
 
 	    /* If we have something other than a SUBREG, we might have
 	       done an expansion, so rerun ourselves.  */
@@ -7300,9 +7299,16 @@ make_compound_operation (rtx x, enum rtx
 	      newer = make_compound_operation (newer, in_code);
 
 	    /* force_to_mode can expand compounds.  If it just re-expanded the
-	       compound use gen_lowpart instead to convert to the desired
-	       mode.  */
-	    if (rtx_equal_p (newer, x))
+	       compound, use gen_lowpart to convert to the desired mode.  */
+	    if (rtx_equal_p (newer, x)
+		/* Likewise if it re-expanded the compound only partially.
+		   This happens for SUBREG of ZERO_EXTRACT if they extract
+		   the same number of bits.  */
+		|| (GET_CODE (newer) == SUBREG
+		    && (GET_CODE (SUBREG_REG (newer)) == LSHIFTRT
+			|| GET_CODE (SUBREG_REG (newer)) == ASHIFTRT)
+		    && GET_CODE (inner) == AND
+		    && rtx_equal_p (SUBREG_REG (newer), XEXP (inner, 0))))
 	      return gen_lowpart (GET_MODE (x), tem);
 
 	    return newer;

  reply	other threads:[~2010-06-28 10:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-25 23:29 H.J. Lu
2010-06-28 10:44 ` Eric Botcazou [this message]
2010-06-28 15:59   ` H.J. Lu
2010-06-28 18:39     ` H.J. Lu
2010-06-28 18:57       ` H.J. Lu
2010-06-29 12:05         ` Eric Botcazou

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=201006281205.11210.ebotcazou@adacore.com \
    --to=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    /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).