[PATCH] D86673: [StackColoring] Conservatively merge Variable in catch(Variable)
Than McIntosh via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Nov 2 08:21:56 PST 2020
thanm added a comment.
In your commit message. you refer to "Conservatively merge &(&Variable) for catch(Variable)" -- this seems like a problematic choice of words/terminology. StackColoring operates on slots, not on addresses of slots.
Also "there is a potion" => "there is an option"
================
Comment at: llvm/lib/CodeGen/StackColoring.cpp:437
+ /// Record the FI slots for which may write memory.
+ BitVector StoreSlots;
----------------
"for which may write memory" is awkward wording. How about "Record the FI slots referenced by a 'may write to memory' instruction?
================
Comment at: llvm/lib/CodeGen/StackColoring.cpp:696
}
+ // There is a bug for using LifetimeStartOnFirstUse in win32.
+ // class Type1 {
----------------
I think it would be better to append this comment to the large block at the start of the file (from lines 103-375), since that's currently the place for discussions about how the algorithm works and the various limitations. You can then refer back up to it here.
================
Comment at: llvm/lib/CodeGen/StackColoring.cpp:708
+ // }
+ // For variable X in catch(X), we put &(&X) into ConservativeSlots
+ // to prevent using LifetimeStartOnFirstUse. Because &(&X) may merged
----------------
This doesn't make sense to me. ConservativeSlots contains slots, not addresses of slots -- I think it would be clearer just to say "we put X into ConservativeSlots".
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D86673/new/
https://reviews.llvm.org/D86673
More information about the llvm-commits
mailing list