This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C (and C++)
- From: Jeff Law <law at redhat dot com>
- To: "Iyer, Balaji V" <balaji dot v dot iyer at intel dot com>, "rth at redhat dot com" <rth at redhat dot com>, "Jason Merrill (jason at redhat dot com)" <jason at redhat dot com>, "Aldy Hernandez (aldyh at redhat dot com)" <aldyh at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 21 Oct 2013 11:46:07 -0600
- Subject: Re: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C (and C++)
- Authentication-results: sourceware.org; auth=none
- References: <BF230D13CA30DD48930C31D4099330003A46B6DF at FMSMSX101 dot amr dot corp dot intel dot com> <526056C1 dot 7050607 at redhat dot com> <BF230D13CA30DD48930C31D4099330003A489631 at FMSMSX101 dot amr dot corp dot intel dot com>
On 10/18/13 15:06, Iyer, Balaji V wrote:
I figured that was the case; it's also what origianlly got me thinking
about memory models. volatile can help with getting the right number of
accesses (though there are cases where it gets in the way). But
volatile is not a fence/barrier :-)
The main reason why I made it volatile (as expressed by the volatil
bool variable) is that I want to make sure these values aren't
optimized by the compiler and the value is fetched from memory on
every access. I have added an explanation to the header comment.
Ok, so this relates to the question about keeping all the structures in
Presumably users never concern themselves with the cilkrts_pedigree
structure, it's entirely hidden, right? So there's no way for a
user to ask for an array of these things, right?
Actually, thinking more about this, we've got to make sure we're
compatible with ICC on this stuff. So if you need to weak the
alignments to be ICC compatible, then, well, we have to do it. If (for
example) the compilers differ on their notion of the structure's
alignment, then you couldn't make an array of them and use it reliably
across the ICC & GCC implementations.
I note you set DECL_ALIGN to BIGGEST_ALIGNMENT, which seems
excessive. Why not compute the natural alignment for that structure
and use that? Similarly for the cilkrts_stack_frame, except that it
seems to use PREFERRED_STACK_BOUNDARY. Is there some reason why
each shouldn't be aligned on whatever boundary the target would
normally align those structures?
Fixed, I now let the compiler set these values
You might consider some sort of interoperatibity test. Obviously the
test wouldn't run if ICC wasn't installed, but having a test to catch
this stuff early (if it ever happens) would be wise.
Good to hear it's a big deal. Once there are multiple implementations
in the wild relying upon them, it'll be an even bigger deal..
These structures don't change often and whenever they do (i.e. fields
get added into it) it is kind of a big deal. So far, when we have
changed - once in the past 3 yrs. or so - we have allowed backward
Such ports could probably start with full barriers, it'd be painful from
a performance standpoint, but as a starting point, sufficient.
We've given it some thought, but have neither the manpower nor
charter to port Cilk to non-Intel architectures. We've done a trial
port to ARM to prove it could be done, but we ran fib (a small
example) once and declared victory. We're sure that more work needs
to be done here and would welcome changes to the runtime to support
other architectures. In particular, most or all uses of
assembly-language instructions should be replaced by compiler
intrinsics and memory barriers probably need to be added for
architectures that have a more relaxed memory model than the x86.
Our hope is that, once Cilk Plus was added to gcc, that members of
the community would help us port the runtime to other architectures.