[PATCH] D67007: [ScopBuilder]Skip getting leader when merging statements to close holes

bin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 30 08:18:05 PDT 2019


bin.narwal created this revision.
bin.narwal added a reviewer: Meinersbur.
bin.narwal added projects: Polly, LLVM.

Hi,

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.  Any comments?

Thanks,


Repository:
  rPLO Polly

https://reviews.llvm.org/D67007

Files:
  lib/Analysis/ScopBuilder.cpp
  test/ScopInfo/granularity_scalar-indep_ordered-2.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D67007.218082.patch
Type: text/x-patch
Size: 4020 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190830/5d1aca7a/attachment.bin>


More information about the llvm-commits mailing list