[PATCH] Scoped NoAlias Metadata

Hal Finkel hfinkel at anl.gov
Fri Jan 10 16:31:04 PST 2014


Ping.

 -Hal

----- Original Message -----
> From: hfinkel at anl.gov
> To: atrick at apple.com, sunfish at google.com, chandlerc at gmail.com, hfinkel at anl.gov
> Cc: llvm-commits at cs.uiuc.edu, nrotem at apple.com, "renato golin" <renato.golin at linaro.org>, nlewycky at google.com
> Sent: Friday, December 13, 2013 6:30:15 PM
> Subject: Re: [PATCH] Scoped NoAlias Metadata
> 
> 
>   I think that this is a good point, and we certainly could think of
>   modeling this with some llvm.noalias.start/llvm.noalias.end
>   intrinsics. I don't think this buys us anything, however:
> 
>   The issue is that that noalias pointers, after inlining, don't not
>   alias with all other pointers in the function, only those which
>   came from the same original function under the same control
>   dependencies. Consequently, we'd still need some way of specifying
>   with which other pointers the noalias pointers don't alias (it is
>   not generally all of them). We could add some additional
>   intrinsics for tagging these other pointers, and some metadata to
>   tie them together. This looks much like the current solution, but:
>     - Involves searching for these intrinsics during AA queries
>     (which seems like it could get expensive)
>     - Seems as though it will prevent some useful instruction
>     combining, reordering, etc. without either removing the AA
>     information, or some complicated gymnastics (and just getting
>     this right in all of the relevant passes seems like a large
>     auditing problem).
> 
>   Done this way does involve more metadata, but I think it is much
>   easier to ensure correctness, yields little overhead in AA, and
>   because passes should drop metadata they don't understand, easier
>   to get right by default.
> 
> http://llvm-reviews.chandlerc.com/D2194
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-commits mailing list