[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