This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP] libomp: runtime part of omp_all_memory task dependence implementation.
ClosedPublic

Authored by AndreyChurbanov on Aug 23 2021, 12:46 PM.

Details

Summary

New omp_all_memory task dependence type is implemented.

Library recognizes the new type via either
(dependence_address == NULL && dependence_flag == 0x80 (set highest bit of 1-byte flag))
or
(dependence_address == SIZE_MAX).

A task with new dependence type depends on each preceding task with any dependence type (kind of a dependence barrier).

Diff Detail

Event Timeline

AndreyChurbanov requested review of this revision.Aug 23 2021, 12:46 PM
hbae accepted this revision.Sep 7 2021, 3:17 PM

LGTM

This revision is now accepted and ready to land.Sep 7 2021, 3:17 PM

Writing up the OMPT interface for omp_all_memory, I realized that treating omp_all_memory individually might not be the best choice, considering that the spec talks about "Reserved Locators".

How final is this compiler interface?

Library recognizes the new type via either
(dependence_address == NULL && dependence_flag == 0x80 (set highest bit of 1-byte flag))
or
(dependence_address == SIZE_MAX).

My suggestion would be to define dependence_flag == 0x80 indicating the presence of a reserved locator, but still use a specific address value to indicate the concrete locator. I guess for the alternative interface with SIZE_MAX, we could use SIZE_MAX-1... for upcoming reserved locators.

Writing up the OMPT interface for omp_all_memory, I realized that treating omp_all_memory individually might not be the best choice, considering that the spec talks about "Reserved Locators".

How final is this compiler interface?

Library recognizes the new type via either
(dependence_address == NULL && dependence_flag == 0x80 (set highest bit of 1-byte flag))
or
(dependence_address == SIZE_MAX).

These are actually two interfaces, and compiler has a choice which one to use.

My suggestion would be to define dependence_flag == 0x80 indicating the presence of a reserved locator, but still use a specific address value to indicate the concrete locator. I guess for the alternative interface with SIZE_MAX, we could use SIZE_MAX-1... for upcoming reserved locators.

If library sees specific address value it ignores the flag value. The specification requires the flag to be set by user to the value "out" or "inout", so it may be simpler for compiler to leave the flag with this value (just a guess as I am not a compiler expert).
To me having two requirements when one is enough only adds unneeded complexity.

I guess the question is, whether we expect more reserved locators will be introduced in the future. Since the spec actually introduced a new section, I thought this might really happen. During OMPT discussion, Deepak also raised the issue, that these future reserved locators might not be limited to inout/out dependencies.
Therefore, I thought it would make sense to let the flag just indicate that this involves a reserved locator and encode the kind of locator in the address argument.

I guess the question is, whether we expect more reserved locators will be introduced in the future. Since the spec actually introduced a new section, I thought this might really happen.

I prefer to wait for a new feature to appear in the specification first, and only then implement it in the runtime. I doubt we can reliably predict what might appear in the specification in future and in what form.

Nothing prevents us to introduce new special flag values or special address values in future. I just think we should not make any actions now in order to guess future possible functionality and implement it in advance.

Note also that currently reserved locators are not bound to the task dependence, they may appear in other parts of the OpenMP specification.