[PATCH] D9375: An llvm.noalias intrinsic

[Daniel Berlin via llvm-commits]

>
>
> The one without loop info, can be readnone.
> The with loop info, we figure that out :)
>
> That sounds great, but I don't have any idea how that would work.
>

At the point in time when I insert the intrinsics, I'm either in the
> inliner or in the frontend, and I don't know anything about loops.
>


> Moreover, I might be inserting the intrinsics into places that won't
> obviously dominate, or be inside, loops until after inlining.
>


> Even if I add loop information to the inliner (which we'll want to do
> anyway), having the inliner each for newly-dominating llvm.noalias
> intrinsics and fix them up with information about the newly-inserted loops
> seems asymptotically unfavorable.
>

Note that if we do loop info in the inliner, and keep it up to date, you
already have all the info you need to fix-them-up, and i guess i don't see
what the issue is.

At worst, all you have to do is track what block these things appear in,
and when loopinfo determines that block has a loop id, you promote them and
give them that loop id...
When it determines a block no longer has a loop id, you demote them.
It already has to do all the real work to keep the loops up to date anyway
...

Alternatively, unless they actually get used during inlining (and i don't
see where they are), promote them post-inlining from one intrinsic to the
other as a pass, since now it will understand the CFG/etc. I don't see this
as a significantly different transform than us requiring/using LCSSA for
most loop passes (though you'd run it right after inlining to make sure
nothing broke them).

Given past experience, i'm very very wary of us trying to have implicit
control flow dependence like this, and to add yet another intrinsic we
expect to generate often, but are marking as read-write, pessimizing plenty
of stuff.
Particularly when we know that, post-inlining, if none of them ended up in
loops, we don't actually care where they go.

I'm fine with having the scope be implicit temporarily because i understand
you are just trying to transmit language level scope info, but at some
point, we should be converting that language level scope info into
something expressed only in terms of llvm's cfg/info/etc if we can.

(and FWIW: i would call this thing llvm.noalias.scope, like you suggested
in one place)

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160815/76899135/attachment.html>