[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 23:24:36 PDT 2020


xiangzhangllvm marked an inline comment as done.
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:
----------------
xiangzhangllvm wrote:
> 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!
@clin1 Thx for your hint!
Now this patch first record the "write Solt" into StoreSlots, and collect the "load Slot" in catchpad.
After doing that, check "write Solt" and "catchpad load Slot", then put it into ConservativeSlots or not.


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

https://reviews.llvm.org/D86673



More information about the llvm-commits mailing list