You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently NOELLE enablers do not necessarily respect the semantics of LLVM's lifetime intrinsics. Consider the following pseudocode:
for i in ...
callllvm.lifetime.start(obj)
obj[i] = x
callllvm.lifetime.end(obj)
...
If you perform a loop distribution on this loop, you may end up with something like the following (inspired by a real example):
for i in ...
obj[i] = x
for i in ...
callllvm.lifetime.end(obj)
for i in ...
callllvm.lifetime.start(obj)
While this won't always lead to perceivable errors, it is incorrect. The current solution is to remove the lifetime markers from modified code after parallelization. However, intermediate bitcode at earlier points in the pipeline can still be wrong. Removing correct lifetime markers can also negatively impact performance. The ideal solution would account for lifetime intrinsics without naively removing any from modified code.
Part of the reason we break these semantics is that these intrinsics are ignored by the PDG analysis, so transformations are not constrained in modifying them as they would be with normal call instructions.
The text was updated successfully, but these errors were encountered:
Currently NOELLE enablers do not necessarily respect the semantics of LLVM's lifetime intrinsics. Consider the following pseudocode:
If you perform a loop distribution on this loop, you may end up with something like the following (inspired by a real example):
While this won't always lead to perceivable errors, it is incorrect. The current solution is to remove the lifetime markers from modified code after parallelization. However, intermediate bitcode at earlier points in the pipeline can still be wrong. Removing correct lifetime markers can also negatively impact performance. The ideal solution would account for lifetime intrinsics without naively removing any from modified code.
Part of the reason we break these semantics is that these intrinsics are ignored by the PDG analysis, so transformations are not constrained in modifying them as they would be with normal call instructions.
The text was updated successfully, but these errors were encountered: