http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-03 08:18:05 UTC --- (In reply to comment #8) > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955 > > > > > > --- Comment #6 from Yuehai Du <duyuehai at gmail dot com> 2011-11-03 > > > 06:24:58 UTC --- > > > Let me see if i understand you correctly, you are saying that there isn't > > > an > > > easy way to fix it without hurting the performance(either consider less IV > > > candidates or dumb down the alias analysis). > > > > Yes. > > > > > so this issue won't be fixed in trunk now? > > > > At least I can't see an easy way out. What I was considering as _maybe_ > > a good final solution would be to remove TARGET_MEM_REF and instead > > have TARGET_MEM_REF_ADDR, which would produce an SSA name where we > > could in turn attach alias info to. The minor downside of that is > > that we lose the ability to directly specify a symbol as the base > > for a TARGET_MEM_REF (which is ironically exactly the point where > > things wreck in this testcase ...) > > or we could just start associating alias info with memory references instead > of with pointers. Either way, this would be a major change. Anyway, let > me have a look at this, perhaps I can come up with something less intrusive. > > > > if in that case, Avoiding the issue by set PARM isn't an option for me. i > > > still want to fix it in our private port even with an ugly patch. can we > > > just > > > add a new field in MEM_REF which specify it is local or non-nolocal > > > store(enum{INVALID, LOCAL, NON-LOCAL}), and only set it in IVOPTS before > > > it > > > rewrite the address. we will check this in is_hidden_global_store(). do > > > this > > > work in Gimple level? but i don't know if RTL optimization still delete > > > this > > > store because we don't keep points-to information. > > > > The issue is not only in is_hidden_global_store (), but the issue > > is that alias analysis thinks the store may only alias the local p1 > > array. Thus you may as well get miscompiles from RTL scheduling as well. > > You could already paper over the issue in question by checking > > if a TARGET_MEM_REF has TMR_OFFSET or TMR_OFFSET2 != NULL_TREE in > > is_hidden_global_store (). Another way would be to make sure we > > bias costs enough to make the situation less likely, for example > > in get_computation_cost_at, make the address_p code unconditional. > > Making a miscompilation "less likely" is really not a good idea; we need to > really fix the problem, even if it means some performance penalty. I agree. I think the main difficulty is to detect this issue reliably (and not too conservatively) - arranging for the TARGET_MEM_REF to look ok from an aliasing point of view shouldn't be too difficult then (simply use a INTEGER_CST zero TMR_BASE and shuffle the real base to TMR_INDEX2).
