This is the mail archive of the
mailing list for the GCC project.
Re: Overhaul middle-end handling of restrict
- From: Michael Matz <matz at suse dot de>
- To: Xinliang David Li <davidxl at google dot com>
- Cc: Richard Biener <rguenther at suse dot de>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 25 Nov 2013 15:19:43 +0100 (CET)
- Subject: Re: Overhaul middle-end handling of restrict
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LNX dot 2 dot 00 dot 1311211832370 dot 11100 at wotan dot suse dot de> <CAAkRFZ+z1Am58ooRS+RuMfBQhr6p18bFUrgV1XkTmoUL-7v2WQ at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1311221109140 dot 8615 at zhemvz dot fhfr dot qr> <CAAkRFZJgA84BKKR=Yr7K-vt0t9nDPD8i7ccRVgWmejGzdPXhoA at mail dot gmail dot com>
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
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.