This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with ivopts


Michael Matz <matz@suse.de> writes:
> On Wed, 6 Jul 2011, Richard Sandiford wrote:
>> > 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.
>> 
>> Actually, I take that back.  Use of (p-q)[n] (hoisted_diff[n]) as an 
>> address is precisely the case in which we've decided we _don't_ want to 
>> apply the optimisation (see the address_p code I quoted).
>
> I know, I was referring to the general case of uses of IVs, not 
> necessarily in address context, it was just easier to write.  The reason 
> for disabling this in address context is not because of having no 
> advantage, but rather because accessing objects without a useful base (and 
> "&obj1 - &obj2" is no useful one) in the past lead to wrong aliasing 
> answers.

Right.

> I wrote the example only to show the situation in which such seemingly 
> strange transformation (building the difference of unrelated entities) is 
> actually helpful.

But what I mean is: even with your starting loop, I'm comparing the
transformation that this code does with the alternative, but rejected,
transformation of simply treating both addresses as separate ivs.  I.e.:

  i=0; i < end; i+=1
    p + i * step;
    q + i * step;
-->
  n=p; n < p+end; n+=step
    n;
    (q-p) + n;

vs.

  i=0; i < end; i+=1 
    p + i * step;
    q + i * step;
-->
  n=p; n < p+end; n+=step, m+=step
    n;
    m;

It seems like, with this extra code, we're going out of our way to do
the first, "clever", transformation, instead of doing the second,
even though both seem to have the same cost in terms of loop operations
and live registers.  So what I'm not sure of is when the first transformation
is a win over the second.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]