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
next prev parent 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).