User Details
- User Since
- Nov 28 2018, 11:44 AM (11 w, 3 d)
Yesterday
LGTM
Just for note: it seems that skipping extracting lifetime.start when lifetime.end can't be lifted (in 2nd option) can again lead to miscompile as in https://reviews.llvm.org/D55967 (assume that markers for x and y in rhs are not lifted). It's safer to extract all lifetime.start markers referencing inputs to mark them all as simultaneously used, as in option (1).
Thu, Feb 14
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).
Tue, Feb 12
LGTM
Fri, Feb 8
Thank you! Could you please commit it? (I don't have access to do it)
Add assertion for the InsertPt
Remove DT construction from CodeExtractor tests
Simplify test
Thu, Feb 7
Fri, Jan 18
lgtm
Jan 4 2019
LGTM
Dec 21 2018
I'm concerned about skipping processing markers for outputs. Currently HotColdSplit and partial inlining do not outline function if number of outputs is not zero (by calling findInputsOutputs()), but this check is unreliable because there is some processing of region before extracting (splitReturnBlocks, splitPHINodesOfEntry, splitPHINodesOfExit) and input/output parameters can be changed (their number may become non-zero). So another question is why this check should be done at all (does it bypass some known problem?) Seems that CodeExtractor does not impose such restrictions.
Dec 3 2018
Thank you! I don't have commit access, could you please submit it?
Dec 1 2018
Fix issue when terminator instruction in predecessor is switch
Add unit test for PHIs with one incoming value from region
Nov 29 2018
Fix comments style
Return assertion back
Verify function consistency before outlining