[PATCH] D105246: [AbstractAttributor] Fold function calls to `__kmpc_is_spmd_exec_mode` if possible

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 9 07:59:34 PDT 2021


jdoerfert added a comment.

In D105246#2866459 <https://reviews.llvm.org/D105246#2866459>, @JonChesterfield wrote:

> Thought about this a little more. I think there's a dead-simple 90% solution available.
>
> -For each internal global
>
> - If it is undef initialized
> - If it is only used by loads and stores (thus no aliasing)
> - If every store writes the same constant
> - Replace every load with that constant, then delete the stores, then delete the global

And if you make it "field-sensitive" now you are almost at https://reviews.llvm.org/D104432 :)
Not sure I'd call that dead-simple but I'm with you.

> That's a very narrow load/store propagation that only applies to globals that are initially undef, which are unusual in most programs, but common where `__shared__` or pteam memory is involved.
>
> If I'm reading some disassembled IR right, it would work for the variables used to report is_spmd and is_uninitialized. For modules that only contain one type of kernel, the overall effect would be the same as the current patch, at much reduced complexity.
>
> Should I type that up? I think we're only looking to reduce the cost of the current/legacy devicertl with this patch. When more serious aliasing analysis comes online it would obsolete the trivial IR transform above, at which point we can delete said transform and keep the verification tests. I particularly like the path to cleanly deleting the pass when it becomes obsolete.
>
> edit: Tried to write a test case for this, but everything I've tried so far gets stripped out by the optimiser already. i.e. the is_spmd_exec_mode calls are already removed. Can you share the test case/application where this is not the case?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105246



More information about the llvm-commits mailing list