[LLVMdev] RFC: Converting byref captures into bycopy

Langmuir, Ben ben.langmuir at intel.com
Mon May 27 08:58:12 PDT 2013


Hi all,

I have been looking at how to convert by-reference captures into by-copy captures for captured statements and possibly C++ lambdas, and am looking for some feedback on my approach.  The motivation for trying to use copy captures is to avoid unnecessary loads that are otherwise required inside the outlined function.  This can be important when the outlined function represents the body of a loop, and cannot be inlined, such as in cilk_for, or using a library-based parallel for with lambdas.

I have been prototyping an LLVM IR pass that can move loads out of a captured statement body when possible.  The approach:

Use named metadata to find the captured statement helpers (or lambda functions), as well as the "kind" of captured region they represent.
e.g.
!capturedstmt.helper = !{!0, !1}
!0 = metadata !{<function1>, metadata !"cilk_for"}
!1 = metadata !{<function2>, metadata !"default"}

For each field in the implicit capture-struct parameter, determine whether it can be "promoted" to a by-copy capture.  This involves
1) checking the type of the field: only pointers to pointers or pointers to primitive types with size <= the original pointer can currently be promoted - this skips types that might require a copy constructor, and ensures that they are cheap to pass by value.
2) looking at the uses of the field in the helper: if the field is used in any operation other than a load, then assume it cannot be promoted
3) looking at the uses of the field in the call-site(s): if the pointer stored in the field may also be passed into the helper in another way, then it cannot be promoted.  I have not implemented anything for this, but I imagine there are existing passes that would be useful here, such as alias analysis.  For captured statements, there is only one call-site to worry about, but in lambdas all call-sites would need to be considered.

If any fields can be promoted, then clone the original function with a new capture struct parameter e.g. {i32**, i32*} -> {i32*, i32}.  Then replace loads of the original field with the value inside the outlined function.  The call-site is updated to  call the new function, and add loads of any arguments that have been promoted.  These loads may be removed by later optimizations.

e.g.
%a = alloca i32
%context = alloca {i32*}
%field = getelementptr inbounds {i32*}* %context, i32 0, i32 0
store i32* %a, i32** %field
call void @__captured_stmt_helper({i32*}* %context)

define void @__captured_stmt_helper({i32*}* %context) {
  %field = getelementptr inbounds {i32*}* %context, i32 0, i32 0
  %load.field = load i32** %field
  %a = load i32* %load.field
  ...
}

Becomes something like

%a = alloca i32
%context = alloca {i32}
%field = getelementptr inbounds {i32}* %context, i32 0, i32 0
%load.a = load i32* %a
store i32 %load.a, i32* %field
call void @__captured_stmt_helper_new({i32}* %context)

define void @__captured_stmt_helper_new({i32}* %context) {
  %field = getelementptr inbounds {i32}* %context, i32 0, i32 0
  %a = load i32* %field
  ...
}

I'd love to hear any feedback about this approach, since I'm not totally convinced yet this should not be done in Clang's AST instead.  Thanks,

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130527/0f8fb570/attachment.html>


More information about the llvm-dev mailing list