[PATCH] D137707: Move "auto-init" instructions to the dominator of their users
serge via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 29 02:38:48 PST 2022
serge-sans-paille added a comment.
Thanks @efriedma for the clarification. I understand your arguments and I think they apply to generic code motion, but I also think we have strong enough hypothesis for this particular pass to not be concerned by these issue.
> If you can prove the address doesn't escape, then the whole multi-threaded thing becomes irrelevant, but I guess we SROA most of those cases anyway, so not sure how helpful that is.
I think we are in that situation
I think that the arguments are:
1. we only move initializer marked as auto-init and whose argument is an alloca.
2. we compute the dominator of the sets of the uses of this alloca (excluding the memory initialization marked as "auto-init")
3. we move the memory initialization marked as "auto-init" before that dominator
As a consequence of 2. and 3. there cannot be sharing of the initialized memory before it is initialized, so we can safely cross a memory barrier (and we're not breaking an existing semantic as the auto-init is inserted by the compiler).
Of course all this would collapse without this strong no-sharing assumptions.
Am I missing something?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D137707/new/
https://reviews.llvm.org/D137707
More information about the llvm-commits
mailing list