Initial fallback implementation #8
Conversation
AlexanderKalistratov
requested review from
PokhodenkoSA,
diptorupd,
1e-to and
DrTodd13
There was a problem hiding this comment.
@AlexanderKalistratov One general thing I'm curious about. Is it the case that nothing gets added to the builder for the parent function before the lowering of the outlined parfor body that may fail? If anything gets added at all then it may be a problem if you reset things and go through another path that maybe starts to add similar code for the CPU fallback. Maybe such code isn't an issue if it isn't used and is therefore eliminated but I'm curious about what you think about this issue.
|
@DrTodd13 At the moment parent function doesn't add any device specific instructions, so there is no such issue right now. In case it would add device specific instructions though it would become a problem and different solution would be required. |
|
Current solution doesn't support case when parent function insert any device specific instructions/do device specific optimization. |
AlexanderKalistratov
force-pushed
the
akalist/cpu_fallback
branch
from
7314e32 to
bffd454
Compare
|
@diptorupd I've added comment about how lowering happens and limitation of such approach. https://github.com/IntelPython/numba/pull/8/files#diff-d8989c7f1e14dfa24fbb582a225d6442R973 |
|
Looks good. Thanks @AlexanderKalistratov. |
lower unknown loops to scf.while
No description provided.