[PATCH] D32789: [ScopInfo] Do not use LLVM names to identify statements

Michael Kruse via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 4 03:55:03 PDT 2017


Meinersbur added a comment.

Some post-commit remarks.



================
Comment at: polly/trunk/include/polly/ScopInfo.h:1714
+  /// The smallest array index not yet assigned.
+  long ArrayIdx = 0;
+
----------------
`long` is 32 bits on 32 bit system and any Windows system. If you really think 32 bits are not enough, could you consider using `long long` or `int64_t`?


================
Comment at: polly/trunk/include/polly/ScopInfo.h:2634
+  /// array.
+  long getNextArrayIdx() { return ArrayIdx++; }
+
----------------
This method has a getter-function name, but has side-effects.

Did you consider passing the ArrayIdx to `ScopArrayInfo`'s ctor instead?


================
Comment at: polly/trunk/lib/Support/GICHelper.cpp:218
+
+  if (UseInstructionNames && Val->hasName())
+    ValStr = std::string("_") + std::string(Val->getName());
----------------
Isn't making it also dependent on `Val->hasName()` a breaking/unrelated change? Before, the number was derived by LLVM taking all Value's into account. Now the id is derived from the order the unnamed value is encountered by Polly.

I wouldn't consider it a compile-time improvement either because LLVM still looks for duplicate name if it has a name. If `UseInstructionNames` is enabled, I'd expect names to be derived consistently by LLVM. It is also not consistent with the other overload and the function's description, which says it's only dependent on `UseInstructionNames`.


================
Comment at: polly/trunk/lib/Support/GICHelper.cpp:219
+  if (UseInstructionNames && Val->hasName())
+    ValStr = std::string("_") + std::string(Val->getName());
+  else
----------------
`ValStr = std::string("_") + Val->getName()` should suffice.


Repository:
  rL LLVM

https://reviews.llvm.org/D32789





More information about the llvm-commits mailing list