cilk_sync in argument list crashes compiler

[VoxSciurorum]

Using gcc's statement expression extension to put a sync in an argument list causes a crash trying to capture a token in an outlined function. It's not immediately clear to me if the problem is in the initial IR or the outliner.

extern int f(int);

void g(int arg)
{
  int x = cilk_spawn(f( ({cilk_sync; 1;}) ));
}

IR:

; ModuleID = 'fsync.cpp'
source_filename = "fsync.cpp"
target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx15.0.0"

; Generated from:
; extern int f(int);
;
; void g(int arg)
; {
;   int x = cilk_spawn(f( ({cilk_sync; 1;}) ));
; }

; Function Attrs: mustprogress noinline optnone ssp uwtable
define void @_Z1gi(i32 noundef %arg) #0 {
entry:
  %arg.addr = alloca i32, align 4
  %x = alloca i32, align 4
  %syncreg = call token @llvm.syncregion.start()
  store i32 %arg, ptr %arg.addr, align 4
  %0 = call token @llvm.taskframe.create()
  %tmp = alloca i32, align 4
  sync within %syncreg, label %sync.continue

sync.continue:                                    ; preds = %entry
  call void @llvm.sync.unwind(token %syncreg)
  store i32 1, ptr %tmp, align 4
  %1 = load i32, ptr %tmp, align 4
  detach within %syncreg, label %det.achd, label %det.cont

det.achd:                                         ; preds = %sync.continue
  call void @llvm.taskframe.use(token %0)
  %call = call noundef i32 @_Z1fi(i32 noundef %1)
  store i32 %call, ptr %x, align 4
  reattach within %syncreg, label %det.cont

det.cont:                                         ; preds = %det.achd, %sync.continue
  sync within %syncreg, label %sync.continue1

sync.continue1:                                   ; preds = %det.cont
  call void @llvm.sync.unwind(token %syncreg)
  ret void
}

; Function Attrs: nounwind willreturn memory(argmem: readwrite)
declare token @llvm.syncregion.start() #1

; Function Attrs: nounwind willreturn memory(argmem: readwrite)
declare token @llvm.taskframe.create() #1

declare noundef i32 @_Z1fi(i32 noundef) #2

; Function Attrs: willreturn memory(argmem: readwrite)
declare void @llvm.sync.unwind(token) #3

; Function Attrs: nounwind willreturn memory(argmem: readwrite)
declare void @llvm.taskframe.use(token) #1

attributes #0 = { mustprogress noinline optnone ssp uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="penryn" "target-features"="+cmov,+cx16,+cx8,+fxsr,+mmx,+sahf,+sse,+sse2,+sse3,+sse4.1,+ssse3,+x87" "tune-cpu"="generic" }
attributes #1 = { nounwind willreturn memory(argmem: readwrite) }
attributes #2 = { "frame-pointer"="all" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="penryn" "target-features"="+cmov,+cx16,+cx8,+fxsr,+mmx,+sahf,+sse,+sse2,+sse3,+sse4.1,+ssse3,+x87" "tune-cpu"="generic" }
attributes #3 = { willreturn memory(argmem: readwrite) }

!llvm.module.flags = !{!0, !1, !2, !3}
!llvm.ident = !{!4}

!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 8, !"PIC Level", i32 2}
!2 = !{i32 7, !"uwtable", i32 2}
!3 = !{i32 7, !"frame-pointer", i32 2}
!4 = !{!"clang version 19.1.7 (git@github.com:OpenCilk/opencilk-project.git 70b9b6ad61d683804a5e2e745bb855642b987d1f)"}

[VoxSciurorum]

If I move the task frame create call

  %0 = call token @llvm.taskframe.create()

from before to after the first sync opt does not crash.

So having a sync in a task frame is confusing. Should the IR be condemned as bad, or does Tapir need to handle this case?

In this program the sync could be optimized out. Some of my test cases don't crash the compiler with -O1 because the confusing sync is gone before Tapir lowering.

[neboat]

I would consider the IR bad in this case.

The taskframe.create designates the start of a region of code that will be outlined into a child function. A sync at that location after the taskframe.create would therefore occur at the start of that child function. The syncregion that that sync uses comes from before the taskframe.create, i.e., the parent function. That means that the sync synchronizes spawned tasks in the parent, which is not allowed.

From the C source code, that taskframe.create is inserted to handle the spawning of f, so that the arguments of that call to f can be processed in a child function (i.e., the spawn helper) before the spawn (more precisely, the detach) occurs. It is not clear to me what a cilk_sync in a statement expression among those call arguments should synchronize. More generally, I'm not sure what would make intuitive sense for cilk_spawns or cilk_syncs to do in statement expressions among spawned function-call arguments. So my inclination would be for clang to disallow this, though I'm open to suggestions.