Page MenuHomePhabricator

[OpenMP] Add source location information to the libomptarget profile

Authored by jdoerfert on Jan 22 2021, 5:44 PM.



In much of the libomptarget interface we have an ident_t object now, if
it is not null we can use it to improve the profile output. For now, we
simply use the ident_t "source information string" as generated by the

Diff Detail

Event Timeline

jdoerfert created this revision.Jan 22 2021, 5:44 PM
jdoerfert requested review of this revision.Jan 22 2021, 5:44 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 22 2021, 5:44 PM
Herald added a subscriber: sstefan1. · View Herald Transcript

Still not perfect but getting there:

tianshilei1992 accepted this revision.Jan 22 2021, 5:54 PM



This comment might not relate to this patch. I'm just wondering, this header file should be a totally new file. Why the code is not using LLVM style?

This revision is now accepted and ready to land.Jan 22 2021, 5:54 PM
jhuber6 added inline comments.Jan 22 2021, 6:11 PM

Is there anything wrong with it besides the variable names? I just forgot that LLVM uses Pascal case for its variables when I wrote it.

tianshilei1992 added inline comments.Jan 22 2021, 6:14 PM

Yeah, those variable and type names.

jhuber6 added inline comments.Jan 22 2021, 6:19 PM

The ident_t type name is just to be compatible with the rest of libomp and I made map_var_info_t as an alias to mimic that. I could fix the variable names real quick.

tianshilei1992 added inline comments.Jan 22 2021, 6:23 PM

That would be perfect!

More profiling and selective at to avoid too coarse grained scopes

Remove leftover

Seems like this patch introduces many unrelated changes.

Seems like this patch introduces many unrelated changes.

One I could split off (if (arg_num) x 2), and one accidental reformat, the rest is "part of the profiling".
The loc might now be available in places it is not used, which is generally speaking not a problem.

Here is how a profile now can look like:

LGTM, it's great to have source location information when profiling.

This revision was landed with ongoing or failed builds.Mon, Jan 25, 8:44 PM
This revision was automatically updated to reflect the committed changes.
grokos added a subscriber: grokos.Tue, Jan 26, 5:09 AM
grokos added inline comments.

I see some inconsistency here. targetDataMapper is an internal libomptarget function (not an API function) and yet it is getting profiled. Same for targetDataContiguous and targetDataNonContiguous. The other 3 internal data-related functions targetDataBegin, targetDataEnd and targetDataUpdate are not. Is this intentional?

jdoerfert added inline comments.Wed, Jan 27, 7:28 PM

Kind of.

There are a few options:

  1. Simply profile the interface. We did this at first. The problem is the omp target entry point does 3 things and it is not too helpful to merge the results of h2d, kernel, and d2h, into a single number (IMHO).
  2. Profile the interface and some internal functions. This is not a bad solution but it is unclear what we gain by also profiling the interface at that point.
  3. What I tried to do here is to pick the functions that correspond to conceptual tasks, like h2d/d2h, kernel execution (which is not a function but scope with name in target below), ..., and then profile those.

Long story short, we can discuss this in the meeting at some point and I'm happy for improvement patches :)