[llvm-dev] [RFC] noalias intrinsic

Alexandre Mutel via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 15 00:38:13 PDT 2017

Thanks for the link, exactly what I was looking for!

Amazing if this is already in a PR review.

From: Hal Finkel <hfinkel at anl.gov>
Sent: Friday, September 15, 2017 4:35 AM
To: Ehsan Amiri; Alexandre Mutel
Cc: LLVM Developers Mailing List
Subject: Re: [llvm-dev] [RFC] noalias intrinsic

Hi, Alexandre,

As Ehsan mentions, this is something we've been planning for a while. I'll likely commit the patches to add the intrinsic soon. As soon as the AA implementation patches (and the patch to use the intrinsic in the inliner) finish the review process, we'll be able to handle this effectively.

In short, yes. :-)


On 09/14/2017 08:15 PM, Ehsan Amiri via llvm-dev wrote:
How is this different from the work that Hal has been doing:


From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Alexandre Mutel via llvm-dev
Sent: Thursday, September 14, 2017 4:34 AM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: [llvm-dev] [RFC] noalias intrinsic


Currently the noalias attribute can be applied on function parameters and return value, or via scoped alias on store.

The problem is that there is no easy way to apply the noalias attribute on a pointer that is loaded indirectly (e.g from the field of an aggregate, or from a memory location - though for this you can still use scoped alias, but they are a lot more intrusive)

The idea would be to provide some kind of intrinsic that can transform a pointer to a noalias pointer, something in the lines of:

define noalias i32* @noalias(i32 *%a) {

  ret i32* %a


What do you think? Would it fit an intrinsic?


LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170915/5798f035/attachment-0001.html>

More information about the llvm-dev mailing list