[llvm-dev] Which pass should be propagating memory copies

[Keno Fischer via llvm-dev]

Hi Peter,

Keno,
>           I suspect that if you, Daniel B., and I were to have an in
> person meeting this would take 5~10 minutes
> For everyone to (in terms D.B. will appreciate) “converge to a fixed
> point” (:-)! of understanding. Meanwhile we
> are stuck with limited email bandwidth, but a meet-up at the next llvm Bay
> Area social might be a good idea.
>

I'm not in the Bay Area, so I'm afraid email will have to do.


> Whether GVN is an appropriate place for this opt is going to hinge on the
> precise details of the calling
> Convention, which you are still being vague about. You are simultaneously
> saying
> 1) the memcpy are necessary
> 2) the memcpy can and should be opt away
> But these two statements are mutually exclusive, so you need to be more
> precise about the CC.
>

The question was not about a calling convention, the memcpys are explicit
in the source language, but we'd like to give
some reasonable assurances that under appropriate circumstances, they'll go
away in the optimizer. If you really want the
whole story in the source language you're welcome to read the appropriate
design discussions. Some links with
various parts of the story.

https://github.com/JuliaLang/julia/pull/21912
https://github.com/JuliaLang/julia/issues/11902
https://github.com/JuliaLang/julia/issues/11610

It's hard for me to assess how informative those links will be to people
who haven't worked with julia a lot,
but that's the references we have anyway.


> Why is this important?, because even if Daniel B. can enhance GVN to “look
> through” the memcpys
> And optimize the loads from the local-stack-copy into loads through the
> original pointer argument,
> And optimize the stores into the local-stack-copy into stores through the
> original pointer argument,
> There is still the issue of deleting the memcpys themselves, which is the
> actual performance problem.
>
> But the rules of the C/C++ programming language aren’t typically going to
> allow these deletions,
> For example if the original pointer argument is passed to another
> function, or the address of any
> Or all of the local stack copy are passed to another function, or simply
> calling *any* function because
> It could by the C/C++ rules modify the original data, requiring the
> memcpys to be preserved.
>

C/C++ semantics are not as important here as is whether the LLVM memory
model allows this transformation.
We generate significantly stronger aliasing information in julia than clang
does in most cases, so while this
clearly needs to be done with the appropriate legality checks on aliasing
and memory order, I do believe the
transformation in the original example is allowable as given. If you think
there's an argument that it is disallowed
according to current IR semantics, that's something I'd be most interested
in.

PS, Don’t be intimidated by writing an IR-to-IR pass, I’ve already written
> one, they are easy.
> Yours will be particularly easy (after verifying the transform is legal)
> as it is just a “replace-all-
> Uses-of” which already exists, deleting the memcpys, and finally deleting
> the stack object.
>

That's certainly not the concern here. We've been doing this for many years
now, so we'd be perfectly
comfortable writing our own pass. Nevertheless, as I mentioned before, we
do try to make things generally
available when we can, and I feel that this is one of those situations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170519/12866a51/attachment.html>