Re: PR 11319 analyzed (Re: Patch fixing 3.3 bug PR 9745 and PR 10021)

[Dale Johannesen <dalej at apple dot com>]

On Tuesday, July 15, 2003, at 12:52  PM, Franz Sirl wrote:
> \Certainly this doesn't set *x to the expected value.
> This testcase quite nicely shows why Dale's "hackish" (why?) patch 
> cured it.
> Dale's patch changes true_dependence() to look at the MEM_EXPRs of the 
> MEMs
> above (what shows up as [4 tr S4 A32] and [4 tr+0 S4 A128] in the 
> above RTL)
> and decides that they describe the same "object" and so the accesses
> conflict.
>
> This raised a few questions for me:
>
> - why is Dale's patch "hackish", except for not curing all possible 
> cases?

Well personally that seems like the only reason, but it's a big reason.
My patch does not fix the real problem in the aliasing code, but 
neither does
Jim's patch, as Franz has demonstrated; from that point of view they're 
equally
hackish.  Mine does fix more of the known occurrences of the bug and 
does
not introduce a performance regression; there are grounds for 
considering it
superior, IMO.

I did run into a case where my patch doesn't work and Jim's does.  This 
is
a case where the array is inside a struct, so the FE-derived aliasing 
info
looks like "x.y.z" instead of "tr" as above.  This prints identically 
in both
memrefs, but the same tree is apparently not used.  This should be easy 
to
fix if you want to go that route.  (I stopped when I did because Jim's 
patch
came by so I tried that instead.)  Or we could apply both patches.

Also, I'm not sure all language FEs provide the info I'm looking at.
C and C++ do though.

We tried Jim's patch (in combination with mine, but that shouldn't 
matter)
on SPEC on ppc Darwin and did not get a performance regression.  Are
you sure the regression on x86 is due to this patch?