[LLVMdev] Loads moving across barriers

[Chandler Carruth]

On Thu, Dec 26, 2013 at 8:54 PM, Andrew Trick <atrick at apple.com> wrote:

> Others can weigh in here. This is just my understanding. Attribute
> propagation has to be optional because we can’t assume inter-procedural
> optimization runs for correct codegen. What if the memfence resides in a
> different module?
>
> In the case of noduplicate, the only reason to propagate AFAICT would be
> to suppress inlining. It seems reasonable enough to expect attribute
> propagation to happen before inlining. So I don't think noduplicate is an
> issue in practice.
>

I think you've misunderstood the specification of noduplicate... This isn't
how it works.

Let's assume we have functions A, B, C, and D. Function A is marked as
'noduplicate' and thus all calls to it are marked 'noduplicate'. Functions
B and C call function A in exactly one place. Function D calls function B
twice, and C in exactly one. place. Functions B and C are internal.
Functions B, C, and D are defined, while function A is only declared.

Only function A and calls to function A are marked as 'noduplicate'. I
don't see any reason why this attribute would be propagated?

Function B cannot be inlined into function D because doing so would
duplicate one of the calls to A. The inliner checks this *while doing the
inlining*, it does not rely on any function attribute on B for correctness
here.

Function C *can* be inlined into function D because there is only one call
site and it is an internal function. Thus, the call to A is not duplicated,
it is merely sunk into D.


So there is no propagation of attributes to achieve correctness even with
noduplicate. The inliner directly checks[1] the callee's call instructions
to ensure that inlining is valid.

I agree with Andy that we should *not* add a requirement to propagate such
attributes.



> I think "memfence" could be an issue if we use the attribute to summarize
> LLVM atomic load/store and fence instructions (in addition to OpenCL
> barriers).
>

I have no idea what semantics you would attach to it in this case. I've not
seen any clear explanation of such semantics yet in this thread.

The only clear semantics I've seen expressed so far seem much more
appropriate for attaching to a noduplicate call to an intrinsic... But I
think I'll need to read this thread again to re-absorb much of the
information after the holidays. =]


[1]: Note, the current implementation of noduplicate is buggy, but
hopefully in a latent way -- it doesn't handle invokes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131226/bc3c82de/attachment.html>