[PATCH] D86673: [StackColoring] Conservatively merge Variable in catch(Variable)

Xiang Zhang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 26 17:54:42 PDT 2020


xiangzhangllvm added inline comments.


================
Comment at: llvm/lib/CodeGen/StackColoring.cpp:706
+          // with object V which may call destructor after write &(&X).
+          //
+          // The loader of &(&X) is the first LOAD MI in EHPad. Some like:
----------------
clin1 wrote:
> It might be worth explaining here that the runtime writes to X outside of the user code, which is why we don't know the exact start of the lifetime.
> Question: Why does a memory read start a stack value lifetime---shouldn't it be a write? And if we don't find a write, then the coloring should be conservative?
> 
Yes, maybe we can check the "write", but I am afraid the "undef" stack-value, it may just has read at first use.

Current stack-coloring code didn't distinguish the read/write status for the stack-mem operand in MI, 
please refer line 611, "InterestingSlots.test(Slot)" mainly check if the stack-slot guard with lifetime.start/end, and 
the applyFirstUse(Slot) is mainly check the LifetimeStartOnFirstUse option.

I'll update the test, thank you a lot!


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

https://reviews.llvm.org/D86673



More information about the llvm-commits mailing list