Copy constructor within spawn not outlined about tapir-llvm

[neboat]

(Finally getting back to this question after a major deadline on my end, and before my next major deadline in a week.)

I agree with your mental model of what should happen in this case. I'm working through a fix, but it might take a while to implement and test.

[neboat]

Thanks for pointing out this issue.

I was in the midst of crafting a long response about why Cilk evaluates all function arguments before the spawn and why your example contains a subtlety — compiler optimizations at -O1 — that makes the behavior appear inconsistent. But thinking about it further, I think your example gets at something deeper concerning object construction and destruction with Cilk and Tapir.

Right now is a particularly busy time for me, but I'll try to get back to you soon.

[ehein6]

Thanks for the quick response, I appreciate any time you can devote to this. Some more thoughts:

The key question is whether child is guaranteed to have a private copy of obj after the detach. I'd argue that it should, to preserve the semantics of pass-by-value during a spawn.

Here's my mental model of what should happen:

1. Parent calls the outlined function det.achd
2. det.achd gets ready to call child, then does a detach.
3. After this point, other workers are free to steal parent's stack frame and continue. This is safe because any arguments passed to child live on det.achd's stack, having been initialized in step 2.

From the IR, it looks like all the detached children will share a single copy of obj created on the stack of parent. But I must be missing something, because on x86 I never observe a race condition bug here.

I've verified that the behavior for this example is the same at -O3.

[ehein6]

Here's an interesting wrinkle: If I give object a user-defined destructor, then suddenly Tapir puts the alloca, constructor call, and destructor call in the outlined function like I expect.

struct object {
    long _value;
    noinline object(long value) : _value(value) {
        *marker = 0xC;
    }
    noinline object(const object& other) {
        *marker = 0xCC;
    }
    noinline ~object() {
        *marker = 0xD;
    }
};
// ...
// The rest is unchanged

; Function Attrs: noinline nounwind uwtable
define internal fastcc void @_Z6parentl_invoke.cont.cilk(i64 %x.cilk, i64 %i.015.cilk, %struct.object* align 8 %obj.cilk) unnamed_addr #2 personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) {
for.body.cilk:
  %__cilkrts_sf = alloca %struct.__cilkrts_stack_frame, align 8
  call fastcc void @__cilkrts_enter_frame_fast_1(%struct.__cilkrts_stack_frame* nonnull %__cilkrts_sf)
  call fastcc void @__cilkrts_detach(%struct.__cilkrts_stack_frame* nonnull %__cilkrts_sf)
  %agg.tmp.cilk = alloca %struct.object, align 8
  %0 = bitcast %struct.object* %agg.tmp.cilk to i8*
  call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %0)
  %call.cilk = call i64 @add(long, long)(i64 %x.cilk, i64 %i.015.cilk)
  %add.cilk = add nsw i64 %i.015.cilk, %x.cilk
  call void @object::object(object const&)(%struct.object* nonnull %agg.tmp.cilk, %struct.object* nonnull dereferenceable(8) %obj.cilk)
  call void @child(long, long, object)(i64 %add.cilk, i64 %call.cilk, %struct.object* nonnull %agg.tmp.cilk)
  call void @object::~object()(%struct.object* nonnull %agg.tmp.cilk) #7
  call fastcc void @__cilk_parent_epilogue(%struct.__cilkrts_stack_frame* nonnull %__cilkrts_sf)
  ret void
}