On 10/18/13 15:06, Iyer, Balaji V wrote:
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.
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 :-)
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?
Ok, so this relates to the question about keeping all the structures in
sync....
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
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.
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.
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
compatibility.
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..
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.
Such ports could probably start with full barriers, it'd be painful from
a performance standpoint, but as a starting point, sufficient.
jeff
