diff options
| author | Jay Foad <jay.foad@amd.com> | 2022-04-21 12:01:59 +0100 |
|---|---|---|
| committer | Jay Foad <jay.foad@amd.com> | 2022-05-05 11:30:31 +0100 |
| commit | ba6c8d42d4dce8776450effe4675c3264b7481dd (patch) | |
| tree | 8b09709a81a9b619ca1617b8a25b325d3954462d /clang/lib/Frontend/CreateInvocationFromCommandLine.cpp | |
| parent | 6f095babc2b7d564168c7afc5bf6afb2188fd6b4 (diff) | |
| download | llvm-ba6c8d42d4dce8776450effe4675c3264b7481dd.zip llvm-ba6c8d42d4dce8776450effe4675c3264b7481dd.tar.gz llvm-ba6c8d42d4dce8776450effe4675c3264b7481dd.tar.bz2 | |
[AMDGPU] Combine DPP mov even if old reg def is in different BB
Given a DPP mov like this:
%2:vgpr_32 = V_MOV_B32_e32 0, implicit $exec
...
%3:vgpr_32 = V_MOV_B32_dpp %2, %1, 1, 1, 1, 0, implicit $exec
this patch just removes a check that %2 (the "old reg") was defined in
the same BB as the DPP mov instruction. GCNDPPCombine requires that the
MIR is in SSA form so I don't understand why the BB matters.
This lets the optimization work in more real world cases when the
definition of %2 gets hoisted out of a loop.
Differential Revision: https://reviews.llvm.org/D124182
Diffstat (limited to 'clang/lib/Frontend/CreateInvocationFromCommandLine.cpp')
0 files changed, 0 insertions, 0 deletions