On Fri, 22 Nov 2013, Xinliang David Li wrote: > On Fri, Nov 22, 2013 at 2:19 AM, Richard Biener <rguent...@suse.de> wrote: > > On Thu, 21 Nov 2013, Xinliang David Li wrote: > > > >> On Thu, Nov 21, 2013 at 10:03 AM, Michael Matz <m...@suse.de> wrote: > >> > Hello, > >> > > >> > after much pondering about the issue we came up with this design to > >> > handle restrict more generally. Without a completely different way of > >> > representing conflicts (or non-conflicts) of memory references we're > >> > bound > >> > to somehow encode the necessary information into the points-to set (or in > >> > any case information related to pointer ssa names). This in turn means > >> > that the location sensitive nature of restrict needs to be made explicit > >> > in the IL, i.e. we basically need some starting point when a pointer > >> > becomes restrict (ADD_RESTRICT), and also an ending point (DEL_RESTRICT), > >> > which must act as barrier for other memory accesses (if it wouldn't some > >> > transformations could move references from outside restrict regions into > >> > the restrict region making them disasmbiguable with the restrict > >> > references, introducing a bug). > >> > > >> > >> Can you use block/scope information to address this ? References from > >> enclosing scopes can be considered possible aliases. > > > > Apart from the issue that LTO drops all BLOCKs this makes the middle-end > > feature too much tied to the C family frontends and their definition > > of restrict. It also requires BLOCK lookup / matching at the time > > of the alias query (which generally deals with "refs" which may > > end up not refering to any BLOCK or to different BLOCKs than the > > GIMPLE they are used in). > > Can the aliaser capture the scope info and maintain its own minimal > block tree? Each ref will have a unique scope id. Code duplication > transformations need to propagate info properly.
Well, certainly. You would need an additional place to refer to the scope id from a GIMPLE stmt (or the tree memory reference). > > > > It also suddenly makes having (correct) BLOCK info cause code generation > > differences. > > Is it an issue if it is not affected by with -g is specified or not? Too many negates for me in this sentence. To re-iterate, -g and -g0 need to create the same code. Also stmts may get BLOCKs assigned that they don't really belong to (harmless now, fatal after using BLOCKs for disambiguation). > > > > That said, you would somehow need to remember the BLOCK a restrict > > "tag" is live in which doesn't make it a good fit for the current > > alias-info we associate with SSA names. If you don't allow > > disambiguations against refs in nested BLOCKs then a single > > "tag" decl with its associated BLOCK is enough to remember > > (thus one additional pointer). > > > > But well - I always wondered how other compilers implement support > > for restrict (and how restricted that support is, and how strictly > > following the standard). > > > > The only other scheme I can come up with is to allow non-dependences > > to be recorded and maintained throughout the compilation and have > > frontends create them. > > It has been a while, but I recall one compiler does similar things -- > pretty early in the middle end before blocks are stripped, per-scope > pointer analysis/tracking is done for scopes with restrict pointer > uses. When that is done, alias pairs that can be disambiguated are > recorded, and this information is maintained throughout (including > inline tranformation). Yeah, that's probably the best method - the issue is reliably maintaining the information. And of course doing the analysis itself on a IL that might not be best suited for the analysis. At some point we should think about adding a facility to maintain non-alias info as that would also speed up repeated queries and allows more costly analysis done (and not repeated). Thanks, Richard.
