http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #8 from rakdver at kam dot mff.cuni.cz <rakdver at kam dot mff.cuni.cz> 2011-11-03 08:06:52 UTC --- > > 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.
