On Fri, Aug 26, 2022 at 01:15:24PM +0200, Tobias Burnus wrote:
> For reverse-offload data handling, we need to support:
> (a) device fn addr -> host fn address
> (b) finding already mapped host -> device vars via their device address
>
> For (a), the functions addrs, we need some extra code (cf. previous patches)
> as this information does not exist already. For (b), the variables, we have
> two options:
> (i) Do a reverse search on the existing data. That's done in
> oacc-mem.c's lookup_dev
> and obviously is O(N) as it has to check all nodes.
> With the assumption "This is not expected to be a common operation."
> is might be still okay.
> (ii) Using a second splay tree for the reverse lookup.
>
> The attached patch prepares for this – but does not yet handle all
> locations and is not yet active. The 'devicep->load_image_func' call
> depends whether the previous [1/3] patch (cf. below) has been applied
> or not.
>
> (The advantage of the reverse-offload mapping is that 'nowait' is not
> permitted and 'target {enter,exit,} data device(anchestor:1)' is neither.
> Thus, all 'omp target device(ancestor:1)' mapping done in target_rev
> can be undone in the same function - and all others are preexisting.)
>
> OK for mainline?
I'd prefer this going in only when somebody actually uses it, and
without the #if 0 parts or
/* , rev_lookup ? &rev_target_fn_table : NULL */
Also, I wonder if the reverse splay tree is recreatable from the normal
splay tree (or at least until something that results in that no longer be
the case) if the reverse splay tree couldn't be created lazily, only when
something actually asks for the reverse offload the first time walk the
whole normal splay tree and populate from it the reverse one and after
that maintain it.
Or at least not key whether to populate it on reverse offload being
requested, but actually some device(ancestor:1) somewhere.
> + /* Likeverse for the reverse lookup device->host for reverse offload. */
Likewise or something else?
Jakub
