public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@linaro.org>
To: Michael Matz <matz@suse.de>
Cc: gcc@gcc.gnu.org
Subject: Re: Help with ivopts
Date: Wed, 06 Jul 2011 13:32:00 -0000	[thread overview]
Message-ID: <g4y60bilgp.fsf@linaro.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1107061456410.17483@wotan.suse.de> (Michael Matz's	message of "Wed, 6 Jul 2011 15:10:06 +0200 (CEST)")

Michael Matz <matz@suse.de> writes:
> On Wed, 6 Jul 2011, Richard Sandiford wrote:
>> The individual difference_cost and add_cost seem reasonable (4 in each 
>> case). I don't understand the reasoning behind the division though.  Is 
>> the idea that this should be hoisted?
>
> Yes, it should be hoisted outside the loop.  The difference is between two 
> loop-invariant values (the bases), and hence is also loop-invariant.  Some 
> tree optimizer should do this already, possibly the casts confuse us.

OK, thanks, suspected as much.

>> If so, then:
>> 
>> (a) That doesn't happen at the tree level.  The subtraction is still inside
>>     the loop at RTL generation time.
>> 
>> (b) What's the advantage of introducing a new hoisted subtraction that
>>     is going to be live throughout the loop, and then adding another IV
>>     to it inside the loop, over using the original IV and incrementing it
>>     in the normal way?
>
> It can reduce address complexity for one of the addresses.  E.g. given:
>
>  i=0; i < end; i+=4 
>    p[i];
>    q[i];
>
> -->
>
>  n=p; n < p+end; n+=4
>    [n];
>    (q-p)[n];
>
> Here (q-p) is loop-invariant, and the complexity of the first address is 
> lower (no offset).  In fact the register pressure is lower by one too 
> (three instead of four, including the end/p+end bound).

But your second loop isn't what I was comparing it with.  I was comparing
it with:

n=p; n < p+end; n+=4, m+=4
  [n]
  [m]

That has the same number of registers (3) and the same number of
additions (2).  And the [m] is what we started with, so it was
actually:

  i=0; i<count; i+=1, n+=4, m+=4
    [n]
    [m]

-->

  i=0; i<count; i+=1, n+=4
    [n]
    (q-p)[n]

(we don't get rid of "i" or "count" in this case.

If the target allows (q-p)[n] to be used directly as an address, and if
the target has no post-increment instruction, then it might be better.
But I think it's a loss on other targets.  It might even be a loss on
targets (like PowerPC IIRC), that need base+index addresses to have
the "real" base first.  This sort of transformation seems to make us
lose track of which register is the base.

Richard

  reply	other threads:[~2011-07-06 13:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-06 11:35 Richard Sandiford
2011-07-06 13:10 ` Michael Matz
2011-07-06 13:32   ` Richard Sandiford [this message]
2011-07-06 13:43     ` Richard Sandiford
2011-07-06 14:40       ` Michael Matz
2011-07-06 15:04         ` Richard Sandiford
2011-07-06 15:17           ` Michael Matz
2011-07-06 15:34             ` Richard Sandiford
2011-07-06 15:56               ` Michael Matz
2011-07-06 17:55                 ` Richard Sandiford

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=g4y60bilgp.fsf@linaro.org \
    --to=richard.sandiford@linaro.org \
    --cc=gcc@gcc.gnu.org \
    --cc=matz@suse.de \
    /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).