[PATCH] D57834: [CodeExtractor] Only lift lifetime markers present in the extraction region

Thu Feb 14 14:07:36 PST 2019

vsk added a comment.

In D57834#1398530 <https://reviews.llvm.org/D57834#1398530>, @kachkov98 wrote:

> 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?

I've posted an example in a follow-up patch: https://reviews.llvm.org/D58253

> 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.

Agreed.

> 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?

I don't think it does. For option (2), I meant, if we can't lift a lifetime.end marker then don't lift the lifetime.start marker either, and also erase all markers for the input to prevent bad stack coloring. It seems that option (1) is both simpler and sufficient.

> 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).

Agreed, this seems unavoidable.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57834/new/

https://reviews.llvm.org/D57834