[PATCH] D57834: [CodeExtractor] Only lift lifetime markers present in the extraction region
Sergei Kachkov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 14 13:31:49 PST 2019
kachkov98 added a comment.
In this example there are two possible entry points in region, so it can't be extracted (first block in region should dominate the others). Maybe there are better examples of issue?
As I understand, correct (but conservative) transformation is to move lifetime.start upwards to some dominator block. According to this, lifting lifetime.start before call must be right. Moving lifetime.end downwards to some post-dominator block is generally incorrect. The case when lifetime.end for the same value occured at every execution path doesn't seem very common, but placing lifetime.end after call gives more accurate information. The thing that is unclear fo me is how erasing all markers for input in case when lifetime.end can't be lifted helps stack coloring?
BTW, it seems there is no simple solution that doesn't reduce stack coloring opportunities in all cases (can't provide information to the caller whether lifetime.end for given value occured or not).
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D57834/new/
https://reviews.llvm.org/D57834
More information about the llvm-commits
mailing list