[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