Hi, On Fri, 22 Nov 2013, Xinliang David Li wrote:
> > 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? It could (somewhen in the future). A BLOCK based scheme (in the middle-end) still wouldn't allow implementing restrict-like semantics of other languages, though. I think that's really a dead end, apart of all the practical problems with it right now. > > 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 something we should try to implement for the next GCC version. It's really the more natural way to express the whole problem. Ciao, Michael.
