Make sure that OMPT is enabled in runtime entry points that access internals of the runtime.
Else, return an appropiate value indicating an error or that the data is not available.
Details
- Reviewers
Hahnfeld protze.joachim jlpeyton hbae omalyshe jmellorcrummey - Commits
- rG32959e683a00: [OMPT] Make sure that OMPT is enabled when accessing internals of the runtime
rG582b183dda6b: [OMPT] Make sure that OMPT is enabled when accessing internals of the runtime
rOMP352611: [OMPT] Make sure that OMPT is enabled when accessing internals of the runtime
rL352611: [OMPT] Make sure that OMPT is enabled when accessing internals of the runtime
rOMP351311: [OMPT] Make sure that OMPT is enabled when accessing internals of the runtime
rL351311: [OMPT] Make sure that OMPT is enabled when accessing internals of the runtime
Diff Detail
- Repository
- rL LLVM
Event Timeline
runtime/src/ompt-general.cpp | ||
---|---|---|
458 ↗ | (On Diff #149756) | Should we put an if (ompt_enabled.enabled) return ompt_get_callback_failure at the very beginning of the function? That seems invariant to the switch-case... |
runtime/src/ompt-specific.cpp | ||
198 ↗ | (On Diff #149756) | Is this needed in internal functions or does it just make things easier? I'm worried that adding these checks to internal functions will degrade performance... |
runtime/src/ompt-general.cpp | ||
---|---|---|
458 ↗ | (On Diff #149756) | You meant if (!ompt_enabled.enabled) right? |
None of this makes sense. If OMPT is not enabled, there should be no call to the ompt_initializer. For that reason, no tool should get pointers to OMPT runtime entry points if OMPT is not enabled. Therefore, the OMPT runtime entry points don’t need to check if OMPT is enabled.
The OMPT tool can decide at multiple points to be inactive, here we look at:
4.2.1.2 Initializing an OMPT Tool
If a tool initializer returns a non-zero value, the tool will be activated for the execution; otherwise, the tool will be inactive.
This tool behavior is represented in line 136 of the test-code. Similar behavior is also expect after the ompt_finalize_tool is added: the tool should be inactive, but the runtime should still not crash or reboot if the tool calls some of the runtime entry points after calling ompt_finalize_tool.
Commenting from my phone without a spec (flying without a net): I think we should change the name of the bit ompt_enabled.enabled to ompt_enabled.activated. That would make joachim’s distinction clear. I was commenting on the setting of OMP_TOOL=enabled. There is a difference between enabled and activated. Simon’s commentary in and about the test case muddled the activated vs. enabled distinction.
I think, we should first make this distinction clear in the OpenMP spec. Then we can change the name of this bit.
I would like to commit this patch before the 7.0 branch.
Changing the name of the bit can be done in a later patch.
@jmellorcrummey do you agree, can you remove your request for changes?
The patch in general looks good to me.
If the name of the variable is an issue, I look forward for a patch fixing this name :)