Which pass / place is optimizing out cilk_spawn if immediately followed by a cilk_sync?

[jasonriedy]

I need to disable that optimization in cases where we've added extra semantics to the spawn, but I cannot find where this optimization occurs. Every time I think I find it, I'm wrong. Including looking for detach-reattach pairs... Unless it's part of the syncregion support. sigh, next place to check.

It's a good optimization in general, but not for this one case of "forcing" a migration on our architecture. That also could map onto intentionally shifting NUMA nodes, etc.

[neboat]

There are two places where this optimization occurs:

• For many simple cases, the SimplifyCFG pass performs this optimization pass alongside many other optimizations. Here's the specific line that's responsible in the current dev branch: https://github.com/OpenCilk/opencilk-project/blob/dev/14.x/llvm/lib/Transforms/Utils/SimplifyCFG.cpp#L7097
• The TaskSimplify pass performs this optimization for more complicated cases that SimplifyCFG cannot handle (e.g., when there's exception-handling code involved). Here's where TaskSimplify performs the optimization: https://github.com/OpenCilk/opencilk-project/blob/dev/14.x/llvm/lib/Transforms/Utils/TaskSimplify.cpp#L253-L256

I believe those are the only two places responsible for this optimization. I don't think you want to disable SimplifyCFG outright to disable the optimization. (Disabling the TaskSimplify pass is more debatable, but I think it also performs other "generally good" optimizations.) You can either remove those lines to disable the optimization, but I think it would be better to predicate this optimization in those two places behind flags.

[jasonriedy]

Thanks! Yeah, I'm going to attach an attribute or similar to disable the elision for the specific call. Overall it's the right thing to do, as are the rest of the related ones.