This is the mail archive of the
gcc-patches@gcc.gnu.org
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>
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.