Re: [patch] Fix regression (Re: Fix PR tree-optimization/41857)

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, Nov 17, 2009 at 4:53 PM, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
> Hi,
>
>> > Tested on s390-ibm-linux and spu-elf with no regressions.
>> > OK for mainline?
>>
>> Ugh. ?Well, good enough for now :(
>>
>> I think TMR is broken as it basically treats the base pointer
>> as "value" compared to everywhere else where pointers have
>> semantics attached (like target type, ref-all status, etc.).
>
> I think you paint TMRs too much evil. ?It's whole point is to be
> a lower-level representation of memory access, corresponding to
> the addressing modes available on the target. ?Thus, you should
> expect to lose some information in the lowering.

But then why try so hard and preserve TMR_ORIGINAL at all?

> I think part of the problem is that TMR and higher-level representation of
> memory accesses are used at the same time, thus confusing the expectations.
> It might be better to lower all memory references to TMRs at some point,
> to make the separation clear.
>
> Anyway,
>
>> Thus, TMR misses 1) alignment,
>
> I don't see how TMR misses alignment information any more than the original
> memory access did.

Fair enough - we do have standard means to extract alignment
from memory reference trees though, but not for TMRs (same
for other standard means to query properties about memory
references - see how the alias-oracle is complicated by TMRs).

>> 2) TBAA info, 3) a working way to query points-to info,
>
> This is IMHO because we store TBAA + points-to information in a wrong way
> (associated with the pointers, rather than with the memory references; and in a
> language-dependent form).

I agree, TBAA should be with the memory access (like we have
on RTL).  But points-to information inherently is associated with
a pointer.  Of course we can stick it onto a memory reference
as well if we like to.

>> 4) a way to recover a base pointer from TMR_ORIGINAL.
>
> Why would you want to do that?

Because of the way TMRs are translated to RTL MEM_REFs.

>> For 4.6 I hope we can dump TMRs alltogether.
>
> How do you plan to represent the choices ivopts mades (taking the addressing modes
> into account)? ?Without a gimple-level representation of addressing modes, the only
> option I see is moving the induction variable optimizations to RTL, which would be
> somewhat difficult,

I am toying with the idea to move ivopts right before expansion.
That would also keep the passes that are now inbetween ivopts and
expansion happy instead of punting on all TMRs.

Of course a clear point of lowering our gimple form is ok with me
as well, just then we should drop this TMR_ORIGINAL stuff.
The middle-end alias-oracle part of the RTL oracle could very well
deal with a TMR as MEM_EXPR, but the RTL part does not.

Thus, it all needs a little TLC, too late for 4.5.

Richard.