public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Guenther <rguenther@suse.de>
To: "William J. Schmidt" <wschmidt@linux.vnet.ibm.com>
Cc: rguenth@gcc.gnu.org, gcc-patches@gcc.gnu.org,	bergner@vnet.ibm.com
Subject: Re: [PATCH] Address lowering [1/3] Main patch
Date: Wed, 20 Jul 2011 09:53:00 -0000	[thread overview]
Message-ID: <alpine.LNX.2.00.1107201057320.810@zhemvz.fhfr.qr> (raw)
In-Reply-To: <1311111755.4429.16.camel@oc2474580526.ibm.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 7030 bytes --]

On Tue, 19 Jul 2011, William J. Schmidt wrote:

> I've been distracted by other things, but got back to this today...
> 
> On Wed, 2011-07-06 at 16:58 +0200, Richard Guenther wrote:
> > Ah, so we still have the ARRAY_REFs here.  Yeah, well - then the
> > issue boils down to get_inner_reference canonicalizing the offset
> > according to what fold-const.c implements, and we simply emit
> > the offset in that form (if you look at the normal_inner_ref: case
> > in expand_expr_real*).  Thus with the above form at expansion
> > time the matching would be applied there (or during our RTL
> > address-generation in fwprop.c ...).
> 
> I put together a simple patch to match the specific pattern from the
> original problem report in expand_expr_real_1.  This returns the code
> generation for that specific pattern to what it was a few years ago, but
> has little effect on SPEC cpu2000 results.  A small handful of
> benchmarks are improved, but most results are in the noise range.  So
> solving the original problem alone doesn't account for very much of the
> improvement we're getting with the full address lowering.
> 
> Note that this only converted the basic pattern; I did not attempt to do
> the extra "zero-offset mem-ref" optimization, which I would have had to
> rewrite for an RTL phase.  I don't see much point in pursuing that,
> given these results.
> 
> > 
> > Another idea is of course to lower all handled_component_p
> > memory accesses - something I did on the old mem-ref branch
> > and I believe I also suggested at some point.  Without such lowering
> > all the address-generation isn't exposed to the GIMPLE optimizers.
> > 
> > The simplest way of doing the lowering is to do sth like
> > 
> >   base = get_inner_reference (rhs, ..., &bitpos, &offset, ...);
> >   base = fold_build2 (POINTER_PLUS_EXPR, ...,
> >                                base, offset);
> >   base = force_gimple_operand (base, ... is_gimple_mem_ref_addr);
> >   tem = fold_build2 (MEM_REF, TREE_TYPE (rhs),
> >                              base,
> >                              build_int_cst (get_alias_ptr_type (rhs), bitpos));
> > 
> > at some point.  I didn't end up doing that because of the loss of
> > alias information.
> 
> My next experiment will be to try something simple along these lines.
> I'll look at the old mem-ref branch to see what you were doing there.
> It will be interesting to see whether the gains generally outweigh the
> small loss of TBAA information, as we saw using the affine-combination
> approach.
> 
> As an FYI, this is the patch I used for my experiment.  Let me know if
> you see anything horrifically wrong that might have impacted the
> results.  I didn't make any attempt to figure out whether the pattern
> rewrite is appropriate for the target machine, since this was just an
> experiment.

I wonder if the code below triggered at all as since we expand from
SSA we no longer see the larger trees in-place but you have to
look them up via SSA defs using get_gimple_for_ssa_name (or the
helper get_def_for_expr).  So I expect that the check for a MULT_EXPR
offset only will trigger if the memory reference was still in the
form of a variable ARRAY_REF (then get_inner_reference will produce
an offset of the form i * sizeof (element)).  I think what we want
to catch here is also the case of *(ptr + i) which will not show
up as ARRAY_REF but as MEM[ptr + 0] where ptr is an SSA name
with a defining statement doing ptr' + i * sizeof (element).

Richard.

> Thanks,
> Bill
> 
> Index: gcc/expr.c
> ===================================================================
> --- gcc/expr.c	(revision 176422)
> +++ gcc/expr.c	(working copy)
> @@ -7152,7 +7152,64 @@ expand_constructor (tree exp, rtx target, enum exp
>    return target;
>  }
>  
> +/* Look for specific patterns in the inner reference BASE and its
> +   OFFSET expression.  If found, return a single tree of type EXPTYPE
> +   that reassociates the addressability to combine constants.  */
> +static tree
> +reassociate_base_and_offset (tree base, tree offset, tree exptype)
> +{
> +  tree mult_op0, mult_op1, t1, t2;
> +  tree mult_expr, add_expr, mem_ref;
> +  tree offset_type;
> +  HOST_WIDE_INT c1, c2, c3, c;
>  
> +  /* Currently we look for the following pattern, where Tj is an
> +     arbitrary tree, and Ck is an integer constant:
> +
> +     base:    MEM_REF (T1, C1)
> +     offset:  MULT_EXPR (PLUS_EXPR (T2, C2), C3)
> +
> +     This is converted to:
> +
> +              MEM_REF (POINTER_PLUS_EXPR (T1, MULT_EXPR (T2, C3)),
> +                       C1 + C2*C3)
> +  */
> +  if (!base
> +      || !offset
> +      || TREE_CODE (base) != MEM_REF
> +      || TREE_CODE (TREE_OPERAND (base, 1)) != INTEGER_CST
> +      || TREE_CODE (offset) != MULT_EXPR)
> +    return NULL_TREE;
> +
> +  mult_op0 = TREE_OPERAND (offset, 0);
> +  mult_op1 = TREE_OPERAND (offset, 1);
> +
> +  if (TREE_CODE (mult_op0) != PLUS_EXPR
> +      || TREE_CODE (mult_op1) != INTEGER_CST
> +      || TREE_CODE (TREE_OPERAND (mult_op0, 1)) != INTEGER_CST)
> +    return NULL_TREE;
> +
> +  t1 = TREE_OPERAND (base, 0);
> +  t2 = TREE_OPERAND (mult_op0, 0);
> +  c1 = TREE_INT_CST_LOW (TREE_OPERAND (base, 1));
> +  c2 = TREE_INT_CST_LOW (TREE_OPERAND (mult_op0, 1));
> +  c3 = TREE_INT_CST_LOW (mult_op1);
> +  c = c1 + c2 * c3;
> +
> +  offset_type = TREE_TYPE (TREE_OPERAND (base, 1));
> +
> +  mult_expr = build2 (MULT_EXPR, sizetype, t2, 
> +		      build_int_cst (offset_type, c3));
> +
> +  add_expr = build2 (POINTER_PLUS_EXPR, TREE_TYPE (t1), t1, mult_expr);
> +
> +  mem_ref = build2 (MEM_REF, exptype, add_expr, 
> +		    build_int_cst (offset_type, c));
> +
> +  return mem_ref;
> +}
> +
> +
>  /* expand_expr: generate code for computing expression EXP.
>     An rtx for the computed value is returned.  The value is never null.
>     In the case of a void EXP, const0_rtx is returned.
> @@ -9034,7 +9091,7 @@ expand_expr_real_1 (tree exp, rtx target, enum mac
>        {
>  	enum machine_mode mode1, mode2;
>  	HOST_WIDE_INT bitsize, bitpos;
> -	tree offset;
> +	tree offset, tem2;
>  	int volatilep = 0, must_force_mem;
>  	bool packedp = false;
>  	tree tem = get_inner_reference (exp, &bitsize, &bitpos, &offset,
> @@ -9051,6 +9108,15 @@ expand_expr_real_1 (tree exp, rtx target, enum mac
>  		&& DECL_PACKED (TREE_OPERAND (exp, 1))))
>  	  packedp = true;
>  
> +	/* Experimental:  Attempt to reassociate the base and offset
> +	   to combine constants.  */
> +	if ((tem2 = reassociate_base_and_offset (tem, offset, TREE_TYPE (exp)))
> +	    != NULL_TREE)
> +	  {
> +	    tem = tem2;
> +	    offset = NULL_TREE;
> +	  }
> +
>  	/* If TEM's type is a union of variable size, pass TARGET to the inner
>  	   computation, since it will need a temporary and TARGET is known
>  	   to have to do.  This occurs in unchecked conversion in Ada.  */
> 
> 
> 

-- 
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

  reply	other threads:[~2011-07-20  9:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 14:51 William J. Schmidt
2011-07-04 14:22 ` Richard Guenther
2011-07-04 15:30   ` Michael Matz
2011-07-05 14:08     ` William J. Schmidt
2011-07-05 14:26       ` Michael Matz
2011-07-05 17:08     ` William J. Schmidt
2011-07-08 14:11     ` William J. Schmidt
2011-07-05 14:06   ` William J. Schmidt
2011-07-06 13:22     ` Richard Guenther
2011-07-06 14:37       ` William J. Schmidt
2011-07-06 15:02         ` Richard Guenther
2011-07-20  0:46           ` William J. Schmidt
2011-07-20  9:53             ` Richard Guenther [this message]
2011-07-20 13:38               ` William J. Schmidt

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=alpine.LNX.2.00.1107201057320.810@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=bergner@vnet.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenth@gcc.gnu.org \
    --cc=wschmidt@linux.vnet.ibm.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).