On Wed, Apr 11, 2012 at 6:15 AM, Alan Modra <amo...@gmail.com> wrote: > 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.
Well - you are expecting generic code to understand your arch-specific UNSPEC. It of course cannot. From reading back a bit I understand that you want alias analysis to consider this a barrier for all memory accesses that all mentioned registers possibly point to? I'd have used (USE (mem:BLK (reg 1))) (CLOBBER (mem:BLK (reg 1))) repeated, for each register (maybe you can avoid the USE if the CLOBBER is implicitely considered a use, or maybe we don't need to care because we do not specify what piece of memory is possibly clobbered, we just specify its base address). Oh, and the above would need to be handled explicitely anyway in alias.c Richard. > -- > Alan Modra > Australia Development Lab, IBM
