[PATCH] D13611: [Polly] Create virtual independent blocks

Michael Kruse via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 1 03:37:57 PST 2015


Meinersbur added inline comments.

================
Comment at: include/polly/ScopInfo.h:1291
@@ +1290,3 @@
+  /// operands properly.
+  using NonTrivialOperandsPairTy =
+      std::pair<InstructionSetTy, OutsideOperandsSetTy>;
----------------
jdoerfert wrote:
> Meinersbur wrote:
> > I think you should clarify that you actually mean a flattened operand _tree_. I think LLVM uses the term operands as the direct arguments/parameters of an instruction.
> Where do you expect a tree here? It actually contains __transitive__ operands and I could add that word.
What is a "transitive operand"?

================
Comment at: lib/Analysis/ScopInfo.cpp:2800
@@ +2799,3 @@
+
+      auto &NonTrivialOperands = NonTrivialOperandsMap[AccessInst];
+      auto &SideEffectOperands = NonTrivialOperands.first;
----------------
jdoerfert wrote:
> Meinersbur wrote:
> > Why for each access separately? Shouldn't this be per-ScopStmt because it only matters for cross-stmt operands?
> I'm not sure what you mean. Why do we look at each access separatly or why do we look at the non-trivial-operands of each access separalty?
This is nested inside a "for (MemoryAccess *MA : Stmt)" loop and NonTrivialOperandsMap is indexed by its AccessInst.

- If an instruction has multiple write access (AFAIK not possible at the moment), the code below would run multiple times over the same AccessInst.

- Multiple instructions in the same Stmt might use the same value, thus its operand tree appears multiple times in this statement. At code generation, each of them would get its own copy of the operand tree, although only one per stmt is necessary (the same tree can be reused for both users)


http://reviews.llvm.org/D13611





More information about the llvm-commits mailing list