aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorDavid Green <david.green@arm.com>2019-09-12 16:00:07 +0000
committerDavid Green <david.green@arm.com>2019-09-12 16:00:07 +0000
commita6e944b1731107c647df7aa2c9b026d6a9818c90 (patch)
tree27c933cbad64ff05a7987fbeedc239c932f71d0c /clang/lib/Frontend/CompilerInvocation.cpp
parentaf11cc7eb5da320066d88a8f6d015e6296f0da25 (diff)
downloadllvm-a6e944b1731107c647df7aa2c9b026d6a9818c90.zip
llvm-a6e944b1731107c647df7aa2c9b026d6a9818c90.tar.gz
llvm-a6e944b1731107c647df7aa2c9b026d6a9818c90.tar.bz2
[CGP] Ensure sinking multiple instructions does not invalidate dominance checks
In MVE, as of rL371218, we are attempting to sink chains of instructions such as: %l1 = insertelement <8 x i8> undef, i8 %l0, i32 0 %broadcast.splat26 = shufflevector <8 x i8> %l1, <8 x i8> undef, <8 x i32> zeroinitializer In certain situations though, we can end up breaking the dominance relations of instructions. This happens when we sink the instruction into a loop, but cannot remove the originals. The Use is updated, which might in fact be a Use from the second instruction to the first. This attempts to fix that by reversing the order of instruction that are sunk, and ensuring that we update the uses on new instructions if they have already been sunk, not the old ones. Differential Revision: https://reviews.llvm.org/D67366 llvm-svn: 371743
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions