Currently NOELLE enablers do not necessarily respect the semantics of LLVM's lifetime intrinsics. Consider the following pseudocode:
for i in ...
call llvm.lifetime.start(obj)
obj[i] = x
call llvm.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 ...
call llvm.lifetime.end(obj)
for i in ...
call llvm.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.
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.