On Fri, Apr 06, 2012 at 05:25:15PM +0200, Olivier Hainque wrote:
> Have you discovered where the problem you are still observing
> is coming from (with another case on 4.4) ? I was planning to look
> into it and realized that maybe you were already doing so.
In gcc-4.4, alias.c:write_dependence_p has
if (DIFFERENT_ALIAS_SETS_P (x, mem))
return 0;
immediately after the tests for (mem:BLK (scratch)) and
ALIAS_SET_MEMORY_BARRIER. On find_num.c the read from the stack arr[]
is alias set 3, the stack tie is alias set 2, so they are seen as not
conflicting.
For mainline we have the same alias sets but with the addresses
involved, (unspec [reg 1] UNSPEC_TIE) and (plus (reg 9) (reg 3)), we
run all the way down to rtx_refs_may_alias_p where ao_ref_from_mem for
the stack tie returns false. So anti_dependence returns true.
Hmm, the fact that alias analysis on mainline treats my fancy barriers
like this says I may as well have not bothered. (mem:BLK (scratch))
performs identically at the moment.
--
Alan Modra
Australia Development Lab, IBM
