[PATCH] D15307: ScopInfo: Harmonize the different ARRAY_KINDs

Tobias Grosser via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 7 14:18:19 PST 2015


grosser created this revision.
grosser added reviewers: jdoerfert, Meinersbur.
grosser added subscribers: llvm-commits, pollydev.
Herald added subscribers: rengolin, aemerson.

Over time different vocabulary has been introduced to describe the different
memory objects in Polly, resulting in different - often inconsistent - naming
schemes in different parts of Polly. We now standartize this to the following
scheme:

  KIND_ARRAY, KIND_VALUE, KIND_PHI, KIND_EXIT_PHI
              | ---------- isScalar ------------|

In most cases this naming scheme has already been used previously (this
minimizes changes and ensures we remain consistent with previous publications).
The main change is that we remove KIND_SCALAR to clearify the difference between
a scalar as a memory object of kind VALUE, PHI or EXIT_PHI and a value (former
KIND_SCALAR) which is a memory object modeling a llvm::Value.

We also move all documentation to the KIND_* enum in the ScopArrayInfo class,
remove the second enum in the MemoryAccess class and update documentation to be
formulated from the perspective of the memory object, rather than the memory
access. The terms "Implicit"/"Explicit", formerly used to describe memory
accesses, have been dropped. From the perspective of memory accesses they
described the different memory kinds well - especially from the perspective of
code generation - but just from the perspective of a memory object it seems more
straightforward to talk about scalars and arrays, rather than explicit and
implicit arrays. The last comment is clearly subjective, though. A less
subjective reason to go for these terms is the historic use both in mailing list
discussions and publications.

---

This is a first draft of a possible harmonization. I originally intended to use
'implicit' instead of scalar, but when going through the code (and the test
cases) the noise this caused got pretty large. Hence, I just used the term
"VALUE" as proposed by Michael instead of "scalar" as name of our 'standard
scalar'. I am pretty happy with this for now, but clearly additional comments
are still welcome.

http://reviews.llvm.org/D15307

Files:
  include/polly/ScopInfo.h
  lib/Analysis/ScopInfo.cpp
  lib/CodeGen/BlockGenerators.cpp
  lib/CodeGen/IslNodeBuilder.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D15307.42108.patch
Type: text/x-patch
Size: 34679 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151207/0dab66ce/attachment.bin>


More information about the llvm-commits mailing list