Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OMPIRBuilder] Improve 'target if' implementation #222

Open
wants to merge 1 commit into
base: amd-trunk-dev
Choose a base branch
from

Conversation

skatrak
Copy link

@skatrak skatrak commented Dec 5, 2024

This patch cleans up support for the 'if' clause on 'target' directives by reusing the existing emitIfClause() function rather than duplicating code. One side effect of this change is that constant 'if' values will no longer result in the generation of branches. Instead, code is generated only for the applicable case.

It also adds a unit test to ensure it works as expected.

This patch cleans up support for the 'if' clause on 'target' directives by
reusing the existing `emitIfClause()` function rather than duplicating code.
One side effect of this change is that constant 'if' values will no longer
result in the generation of branches. Instead, code is generated only for the
applicable case.

It also adds a unit test to ensure it works as expected.
Copy link

@mjklemm mjklemm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, albeit not a true expert in this area.

Copy link

@ergawy ergawy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Sergio, just one comment/concern about using cantFail.

llvm::OpenMPIRBuilder::InsertPointOrErrorTy AfterIP = [&]() {
// Assume no error was returned because EmitTargetCallFallbackCB doesn't
// produce any.
llvm::OpenMPIRBuilder::InsertPointTy AfterIP = cantFail([&]() {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does not adding cantFail in this case introduce assumptions about the internals of all called functions/callbacks (e.g. in this instance, the internals of emitKernelLaunch)?

The same question also applies to some of the later uses of cantFail in the PR.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple have been added, but most of these assumptions were already there before the change. I just wasn't familiar with the existence of cantFail() at the time, so wherever possible I just forwarded an error knowing it would never happen and in other places I added a comment saying it couldn't fail, but was still checking the result so that it could be used (it causes runtime failures if you don't check these, even if they succeed). llvm#115863 intends to straighten out other places where this is the case.

The idea with introducing Errors to the OMPIRBuilder was that they could only be caused by callbacks passed from outside. That way, if something failed there, the OMPIRBuilder could stop early and forward the error. So, if we have control over all callback contents, as it's the case here, we know in advance that no errors can be returned. In that case, I believe it's better to not forward these errors to the caller because it's misleading about possibly failing and forces callers to handle that impossible error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants