This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Overhaul middle-end handling of restrict


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]