Page MenuHomePhabricator

[OMPT] Fix test tasks/serialized.c with optimization

Authored by Hahnfeld on Feb 12 2018, 6:57 AM.



The compiler inlines the user code in the task. Check for that case at
runtime by comparing the frame addresses and print the expected exit

Also showcase how I think the OMPT tests could be reformatted to match
LLVM's code style. In my opinion it would be great to that kind of change
to all tests that need to be touched for whatever reason...

Diff Detail


Event Timeline

Hahnfeld created this revision.Feb 12 2018, 6:57 AM

Found a small issue with CHECK.
All other LGTM.

146 ↗(On Diff #133853)

Looks like parallel_id should be checked for PARALLEL_ID here.
Same on line 149.

Hahnfeld added inline comments.Feb 14 2018, 7:23 AM
146 ↗(On Diff #133853)

This doesn't work, parallel_id=0 for these two events. I'd guess that's because the parallel region ended in the barrier, @protze.joachim?

This doesn't work, parallel_id=0 for these two events

Indeed. parallel_end event somehow goes before barrier_end and imlicit_task_end
281474976710657: ompt_event_barrier_end: parallel_id=281474976710660, task_id=281474976710661, codeptr_ra=0x40131b
281474976710657: ompt_event_implicit_task_end: parallel_id=0, task_id=281474976710661, team_size=2, thread_num=0
281474976710657: ompt_event_parallel_end: parallel_id=281474976710660, task_id=281474976710658, invoker=2, codeptr_ra=0x40131b
281474976710657: ompt_event_thread_end: thread_id=281474976710657
562949953421313: ompt_event_wait_barrier_end: parallel_id=0, task_id=562949953421314, codeptr_ra=(nil)
562949953421313: ompt_event_barrier_end: parallel_id=0, task_id=562949953421314, codeptr_ra=(nil)
562949953421313: ompt_event_implicit_task_end: parallel_id=0, task_id=562949953421314, team_size=0, thread_num=1

This behavior is right (p.417,l.5):

The binding of argument parallel_data is the current parallel region. For the implicit-task-end
event, this argument is NULL.

And since we cannot access the ID, if NULL is passed as the address of parallel_data, the callback prints 0.

The reason for this behavior is that barrier-end and implicit-task-end of worker threads is not synchronized with the parallel-end of the master and therefore the parallel-data is most probably gone at that point.

146 ↗(On Diff #133853)

Yes, parallel_id=0 would be the right check for all worker threads.

146 ↗(On Diff #133853)

Sorry, for all threads.

Hahnfeld updated this revision to Diff 134281.Feb 14 2018, 11:35 AM
Hahnfeld marked an inline comment as done.

Test parallel_id in {implicit_task,barrier}_end events. Note that this reveals a bug that I intend to fix separately.

146 ↗(On Diff #133853)

Ok, that turns out to be a bug for master threads. I've posted a fix in D43308.

Ping, anything else left?

This revision is now accepted and ready to land.Feb 23 2018, 8:01 AM
This revision was automatically updated to reflect the committed changes.