aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorMichael Kruse <llvm@meinersbur.de>2019-09-13 01:04:38 +0000
committerMichael Kruse <llvm@meinersbur.de>2019-09-13 01:04:38 +0000
commit87baae85cdee84b43986f1d8d0fac469c7e9521b (patch)
treec4e6456a5b23b17e2b6b010b2b5496efaf1f02d4 /clang/lib/Frontend/CompilerInvocation.cpp
parent4d3391803462433b05a3344e6c37435f725637c4 (diff)
downloadllvm-87baae85cdee84b43986f1d8d0fac469c7e9521b.zip
llvm-87baae85cdee84b43986f1d8d0fac469c7e9521b.tar.gz
llvm-87baae85cdee84b43986f1d8d0fac469c7e9521b.tar.bz2
[ScopBuilder] Skip getting leader when merging statements to close holes.
Function joinOrderedInstructions merges instructions when a leader is encountered twice. It also notices that leaders in SeenLeaders may lose their leadership in previous merging, and tries to handle the case using following code: Instruction *PrevLeader = UnionFind.getLeaderValue(SeenLeaders.back()); However, this is wrong because it always gets leader for the last element of SeenLeaders, and I believe it's wrong even we get leader for Prev here. As a result, Statements in cases like the one in patch aren't merged as expected. After investigation, I believe it's unnecessary to get leader instruction at all. This is based on fact: Although leaders in SeenLeaders could lose leadership, they only lose to others in SeenLeaders, in other words, one existing leader will be chosen as new leader of merged equivalent statements. We can take advantage of this and simply check if current leader equals to Prev and break merging if it does. The patch also adds a new test. Patch by bin.narwal <bin.narwal@gmail.com> Differential Revision: https://reviews.llvm.org/D67007 llvm-svn: 371801
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions