Because Cilk++ allocated a function's frame from the heap, it used a different linkage than standard C/C++ functions. As a result, you could only call a Cilk++ function from another Cilk++ function, since only the Cilk++ compiler knew how to call a Cilk++ function.

One of the major benefits of Intel Cilk Plus is that we got rid of Cilk++ linkage. Cilk Plus functions use standard C/C++ calling conventions and you can freely call a Cilk Plus function from C or C++.

So the compiler didn'tcomplain aboutyoucalling your Cilk Plus function from a C function because it's perfectly legal.

If you look in the Intel Cilk Plus version of cilk.h, you'll see thatother than comments,the file consists of

#ifndef cilk_spawn # define cilk_spawn _Cilk_spawn # define cilk_sync _Cilk_sync # define cilk_for _Cilk_for #endif

All it's doing is making it easier for you to use the Cilk keywords. The Cilk++ version was **MUCH** more complex.

- Barry

Intel Cilk Plus uses standard C/C++ linkage. You can spawn a C or C++ function, just like you can spawn a Cilk function. The following should be entirely legal:

#include #include int main(int argc, char **argv) { printf ("Called before the spawn\n"); cilk_spawn printf("Hello world!\n"); printf ("Now I'm racing!\n"); cilk_sync; printf ("After the race. Who won?\n"); return 0; }

When you spawn a function, the compiler generates a "spawn helper" which encapsulates any temporaries so they're destructed after the spawned function returns. So all of the "magic" is in the call site.

The only thing that cilk/cilk.h does is define macros to make the keywords easier to type. If you used _Cilk_spawn, _Cilk_sync and _Cilk_for, you wouldn't need to include cilk/cilk.h at all.

- Barry

A Cilk function contains a cilk_spawn. When the compiler sees this, it notes that the function must do all those things that a Cilk function does. Among other things, it must initialize a __cilkrts_stack_frame stucture and call __cilkrts_leave_frame in the epilogue. That's all handled later, during code generation.

> How does the compiler kow when a function is c/c++ or cilk? It just seems to not matter.
> Any cilk function can call any one of the three.

Correct.

• Any Cilk function can call or spawn a Cilk function, or any C or C++ function.
• Any C/C++ function can calla Cilk function, or any other function it would able to call normally.

> We do not apparently have any signals no indication that a cilk function is a cilk function.

Correct. Is there some reason you need to know?

- Barry

> If you have a function that is called in several other functions, can it be cilk_spawn -ed in some functions > and just a called c function in the rest?

Yes. As I stated above, when you cilk_spawn a function call, the compiler generates a "spawn helper" which encapsulates any temporaries, so they don't disappear before the spawned function returns. If you run your application with a single worker, debug it, and set a breakpoint in a spawned function, you'll see the spawn helper on the stack. All of the "magic" is at the call site. So you can cilk_spawn a function or call it, at your whim.

As you also noted, while spawns are (relatively) cheap, they're not free. Making a function a "Cilk function" requires initializing a __cilkrts_stack_frame structure which makes a thread-local storage location lookup. You should use them only where you need them. Also note that adding a cilk_for to a function does not make it a "Cilk function." cilk_for is implemented by making a lambda function out of the loop body and passing it into the Cilk runtime. All of the "Cilkiness" for cilk_for is encapsulated in the runtime.

- Barry