[llvm-dev] [RFC] noalias intrinsic

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 14 19:35:03 PDT 2017


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. :-)


  -Hal


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:
>
> https://reviews.llvm.org/search/query/qa3.P4sG6bA8/#R
>
> https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf
>
> *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
> *Subject:* [llvm-dev] [RFC] noalias intrinsic
>
> Hello,
>
> 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?
>
> Alexandre
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
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/20170914/a90c02de/attachment.html>


More information about the llvm-dev mailing list