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: PR 11319 analyzed (Re: Patch fixing 3.3 bug PR 9745 and PR 10021)


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?



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