[llvm-dev] Is every intrinsic norecurse?

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 25 20:04:50 PDT 2017


On 10/20/2017 12:36 AM, Daniel Berlin via llvm-dev wrote:
>
>
> On Thu, Oct 19, 2017 at 10:23 PM, Mikael Holmén via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     Hi,
>
>     Also, I think there is a bigger problem lurking than just with
>     norecurse.
>
> Yes
>
>     I think that in general, functionattrs is not very good with
>     attributes when intrinsics are present.
>
>
>     E.g.
>     https://bugs.llvm.org/show_bug.cgi?id=34696
>     <https://bugs.llvm.org/show_bug.cgi?id=34696>
>
>     Here dbg.value prevents both norecurse and readnone from being
>     deduced.
>
>
> A lot of these are the more general issue of intrinsics not being 
> marked with proper memory attributes as a form of attempted control 
> dependence/optimization blocking/etc
>
> Intrinsics.td even says this.
>
>
>     So, it would be nice to fix this for norecurse, but it would be
>     even nicer to fix it for intrinsics and attributes in general.
>
>
> Nobody as of yet has signed up to fix this, because it often requires 
> significant thinking about each intrinsic and what really should be 
> happening to it, modeling that, and teaching optimizers to deal with it.
>
> Instead the large hammer is chosen.
>
> Eventually it'll matter enough to performance for someone to do the 
> work :)

I agree with this, but I also agree with Sanjoy: We should add a 
NoRecurse property and mark intrinsics with it. This fits our general 
scheme for intrinsics (i.e., "if we say nothing, we assume the worst").

The fact that we model all sorts of dependencies as memory dependencies 
is also a problem, but a somewhat independent one.

  -Hal

>
>
>
> _______________________________________________
> 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/20171025/c9627a0c/attachment-0001.html>


More information about the llvm-dev mailing list