This is an archive of the discontinued LLVM Phabricator instance.

Add OMPT events for API locking
ClosedPublic

Authored by tcramer on Oct 13 2015, 2:17 AM.

Details

Summary

This fix implements the following OMPT events for the API locking routines:

  • ompt_event_acquired_lock
  • ompt_event_acquired_nest_lock_first
  • ompt_event_acquired_nest_lock_next
  • ompt_event_init_lock
  • ompt_event_init_nest_lock
  • ompt_event_destroy_lock
  • ompt_event_destroy_nest_lock

For the acquired events the depths of the locks ist required, so a return value was added similiar to the return values we already have for the release lock routines.

Diff Detail

Repository
rL LLVM

Event Timeline

tcramer updated this revision to Diff 37224.Oct 13 2015, 2:17 AM
tcramer retitled this revision from to Add OMPT events for API locking.
tcramer updated this object.
tcramer added reviewers: jmellorcrummey, jlpeyton.
tcramer set the repository for this revision to rL LLVM.
tcramer added a subscriber: openmp-commits.

The lock init and acquired callbacks are conditionally included according to #if OMPT_SUPPORT && OMPT_BLAME

The proper condition should be #if OMPT_SUPPORT && OMPT_TRACE

I notice that there aren't any patches to kmp_gsupport.c. I looked in that file and didn't see any support for locking. What will happen when using gcc with this support? Will the instrumented locking routines be called to generate the promised callbacks?

I notice that there aren't any patches to kmp_gsupport.c. I looked in that file and didn't see any support for locking. What will happen when using gcc with this support? Will the instrumented locking routines be called to generate the promised callbacks?

Yes these functions will be called. The OpenMP lock functions are simply normal C functions which are called by the compiler just like any other extern function. They are not name-mangled in a compiler specific fashion, or generated in any special way, so the correct functions will be called at no extra effort.

In reading this patch over again, I realized that you implemented the OMPT TR2 lock initialization callback rather than the OMPT working draft, which also passes a lock hint and a lock type to the init callback. The OMPT implementation in LLVM OpenMP is evolving with the current version of the OMPT draft. There are features already in the code that aren't in OMPT TR2. Fort that reason, I think you should add the lock hint and lock type parameters.

tcramer updated this revision to Diff 37260.Oct 13 2015, 9:21 AM
tcramer edited edge metadata.

Changed OMPT_BLAME to OMPT_TRACE for the acquire, init and destroy lock events (thanks John for reading the patch carefully!).

I notice that there aren't any patches to kmp_gsupport.c. I looked in that file and didn't see any support for locking. What will happen when using gcc with this support? Will the instrumented locking routines be called to generate the promised callbacks?

Yes these functions will be called. The OpenMP lock functions are simply normal C functions which are called by the compiler just like any other extern function. They are not name-mangled in a compiler specific fashion, or generated in any special way, so the correct functions will be called at no extra effort.

Yes, seems to work for me. I just verified with gcc 5.2.

In reading this patch over again, I realized that you implemented the OMPT TR2 lock initialization callback rather than the OMPT working draft, which also passes a lock hint and a lock type to the init callback. The OMPT implementation in LLVM OpenMP is evolving with the current version of the OMPT draft. There are features already in the code that aren't in OMPT TR2. Fort that reason, I think you should add the lock hint and lock type parameters.

Thats true. However, the OpenMP runtime library routine "omp_init_lock_with_hint" seems not to be implemented at the moment, because it will come with OpenMP 4.5 (aka 4.1). Thus, I can only pass a hard-coded 0 (which will be omp_lock_hint_none) as hint at the moment.

I agree that the lock type is already implementable, but since it is a change in OMPT infrastructure itself, it should be a separated patch anyway.

I would propose to use the old signature for now and change it as soon as we have the new locking library routine. Does that sound reasonable?

I am fine with the approach proposed below. We can refine the interface at a later date when the lock hints become available.

John Mellor-Crummey Professor
Dept of Computer Science Rice University
email: johnmc@rice.edu phone: 713-348-5179

jlpeyton accepted this revision.Oct 16 2015, 9:52 AM
jlpeyton edited edge metadata.

LGTM.

This revision is now accepted and ready to land.Oct 16 2015, 9:52 AM
This revision was automatically updated to reflect the committed changes.