[HIP] Refactor error handling in enqueue.cpp#1190
[HIP] Refactor error handling in enqueue.cpp#1190aarongreig merged 2 commits intooneapi-src:mainfrom
Conversation
aarongreig
force-pushed
the
aaron/refactorHipEnqueueErrors
branch
2 times, most recently
from
f614c49 to
c451bf2
Compare
aarongreig
force-pushed
the
aaron/refactorHipEnqueueErrors
branch
from
c451bf2 to
f837719
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #1190 +/- ##
=======================================
Coverage 15.46% 15.46%
=======================================
Files 238 238
Lines 33883 33883
Branches 3747 3747
=======================================
Hits 5239 5239
Misses 28593 28593
Partials 51 51 ☔ View full report in Codecov by Sentry. |
jchlanda
left a comment
jchlanda
left a comment
There was a problem hiding this comment.
Really like this, needless accumulation of error codes in Result-like variables, instead of straight out returns, and not using UR_CHECK_ERROR are one of my top pet hates. Thank you!
aarongreig
force-pushed
the
aaron/refactorHipEnqueueErrors
branch
from
f837719 to
0011dd3
Compare
|
@npmiller please take a look when you can |
npmiller
left a comment
npmiller
left a comment
There was a problem hiding this comment.
LGTM, sorry about the late review!
aarongreig
force-pushed
the
aaron/refactorHipEnqueueErrors
branch
from
a2c1f16 to
f989b69
Compare
aarongreig
force-pushed
the
aaron/refactorHipEnqueueErrors
branch
from
f989b69 to
5ebd333
Compare
source/adapters/hip/enqueue.cpp
Outdated
| // but currently unmapped advice arguments as not supported by this | ||
| // platform. Therefore, warn the user instead of throwing and aborting | ||
| // the runtime. | ||
| if (Result == UR_RESULT_ERROR_INVALID_ENUMERATION) { |
There was a problem hiding this comment.
I may be missing something here but is this if (Result == UR_RESULT_ERROR_INVALID_ENUMERATION) meant to be checked again inside the above if (Result == UR_RESULT_ERROR_INVALID_ENUMERATION)? It is already true in this case. Was it meant to be wrapped in if (Result != UR_RESULT_SUCCESS) -> check if equals invalid then msg and return else throw?
There was a problem hiding this comment.
I think I messed up the rebase here, now it just falls through to UR_CHECK_ERROR(Result) if we aren't doing the adapter specific thing
There was a problem hiding this comment.
Yeah that makes sense to me now. Thanks, I actually thuoght it must've been a dodgy rebase by the looks of it.
Mostly by taking the existing try/catch/UR_CHECK_ERROR based approach and making sure it's used consistently so as not to drop any errors.
aarongreig
force-pushed
the
aaron/refactorHipEnqueueErrors
branch
from
d070776 to
96468e2
Compare
7 participants
LLVM testing intel/llvm#12481