On Tue, Aug 27, 2013 at 03:55:38PM +0400, Michael V. Zolotukhin wrote:
> > What I meant was just that if you call GOMP_target with
> > num_descs N, then the structure will look like:
> > struct .omp_target_data
> > {
> > sometype0 *var0;
> > sometype1 *var1;
> > ...
> > sometypeNminus1 *varNminus1;
> > };
> > so pretty much the runtime will call the target routine with address of
> > an array of N pointers, and the compiler generated target routine will
> > just use a struct to access it to make it more debuggable. As there won't
> > be any paddings in the structure, I'd hope the structure layout will be
> > exactly the same as the array.
> Ok, such assumption about struct layout seems to be enough for runtime
> to figure out what to translate.
> I'll try to put to rights everything we've discussed and prepare some
> description of the overall scheme. After that, if you are ok with that,
> we could start implementing it - that's the time we'll face the most
> interesting stuff I guess:)
Perhaps instead of passing array of { void *hostaddr; size_t length; char kind;
}
and length we could pass 3 arrays and length (the same for all of them).
I can see 2 advantages of doing that:
1) the sizes are often constant and the kinds are always constant, so
we could often allocate those last 2 or just last array in .rodata, wouldn't
need to initialize it dynamically
2) for the host fallback, we could just pass the first array unmodified as
the .omp_target_data structure, no need to copy the host addresses
Jakub
