This is an archive of the discontinued LLVM Phabricator instance.

[Polly] ScopInfo: Harmonize the different ARRAY_KINDs
ClosedPublic

Authored by grosser on Dec 7 2015, 2:18 PM.

Details

Summary

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.

Diff Detail

Event Timeline

grosser updated this revision to Diff 42108.Dec 7 2015, 2:18 PM
grosser retitled this revision from to ScopInfo: Harmonize the different ARRAY_KINDs.
grosser updated this object.
grosser added reviewers: jdoerfert, Meinersbur.
grosser added subscribers: llvm-commits, pollydev.
Meinersbur edited edge metadata.Dec 9 2015, 5:13 AM

I welcome any consistent naming scheme.

MemoryAccess::print still prints "[SCALAR: 0]" or "[SCALAR: 1]". It should maybe print the kind instead, although this requires a lot of unit tests to change.

KIND_VALUE fits because it originates from an llvm::Value, analogously to a KIND_PHI originating from an llvm:PHINode. The reason I did not name like this in my first commit is that we have WRITE MemoryAccesses to such "values", but values are not written to (like variables), but defined.

I kind of liked the distinction of implicit/explicit (i.e. whether it comes from an explicit LoadInst/StoreInst or it is a result of how we model scalars), but it might also be orthogonal to the array kind.

include/polly/ScopInfo.h
119

array of arbitrary dimensionality.

multi-dimensional could be understood as at least 2 dimensions.

600–601

ScopArrayInfo::KIND, ARRAYKIND, KIND_ARRAY is confusing.

I don't think ScopArrayInfo::KIND is too long to require a typedef, but if, it should have the same name as the declaration in ScopArrayInfo. The individual values (e.g. ScopArrayInfo::KIND_ARRAY) still need to be fully qualified.

LLVM's style guide says the enum type names should not be all caps, and uses "Kind" as suffix instead of prefix.

696

The function name sounds gramatically wrong.

I welcome any consistent naming scheme.

MemoryAccess::print still prints "[SCALAR: 0]" or "[SCALAR: 1]". It should maybe print the kind instead, although this requires a lot of unit tests to change.

Scalar:0 and Scalar: 1 is technically not wrong, but clearly we code print more precise information. However, this seems to be a separate patch (especially due to the unit-test noise it will cause).

KIND_VALUE fits because it originates from an llvm::Value, analogously to a KIND_PHI originating from an llvm:PHINode. The reason I did not name like this in my first commit is that we have WRITE MemoryAccesses to such "values", but values are not written to (like variables), but defined.

You are right that values are not written. Still, I am very happy with this name due to the llvm::Value correspondance.

I kind of liked the distinction of implicit/explicit (i.e. whether it comes from an explicit LoadInst/StoreInst or it is a result of how we model scalars), but it might also be orthogonal to the array kind.

Right.

include/polly/ScopInfo.h
119

Now:

"Models a one or multi-dimensional array"

600–601

ScopArrayInfo::KIND, ARRAYKIND, KIND_ARRAY is confusing.

We are now left with ScopArrayInfo::MemoryKind and
ScopArrayInfo::MK_Array.

I don't think ScopArrayInfo::KIND is too long to require a
typedef, but if, it should have the same name as the
declaration in ScopArrayInfo. The individual values (e.g.
ScopArrayInfo::KIND_ARRAY) still need to be fully
qualified.

I dropped the typedef.

LLVM's style guide says the enum type names should
not be all caps, and uses "Kind" as suffix instead of
prefix.

I now follow the llvm style guide:

"Enumerators (e.g. enum { Foo, Bar }) and public member variables should start with an upper-case letter, just like types"

"enumerators should have a prefix corresponding to the enum declaration name. For example, enum ValueKind { ... }; may contain enumerators like VK_Argument, VK_BasicBlock, etc"

696

I now moved to hasKindArray(). Does this sound better?

I could also use isArrayKind(), but I would like the different Kind* functions to be close by alphabetically such that they can be easy found when autocompleting.

grosser updated this revision to Diff 42394.Dec 10 2015, 12:48 AM
grosser edited edge metadata.

Addressed Michael's comments

grosser updated this revision to Diff 42395.Dec 10 2015, 12:51 AM

Add some missed KindValue -> MK_Value transformations

grosser retitled this revision from ScopInfo: Harmonize the different ARRAY_KINDs to [Polly[ ScopInfo: Harmonize the different ARRAY_KINDs.Dec 10 2015, 12:52 AM
grosser retitled this revision from [Polly[ ScopInfo: Harmonize the different ARRAY_KINDs to [Polly] ScopInfo: Harmonize the different ARRAY_KINDs.
Meinersbur added inline comments.Dec 10 2015, 2:09 AM
include/polly/ScopInfo.h
309

Rename to hasKindPHI() for consistency with MemoryAccess::hasKindPHI?

600–602

The style guide also seem to prefer consistency with existing styles. enum AccessType uses all caps values. We could change it as well (in a different patch).

696

Personally, I'd prefer isArrayKind() or isArrayAccess(). No objective reasons.

grosser updated this revision to Diff 42402.Dec 10 2015, 2:39 AM
grosser marked an inline comment as done.

Address Michael's comments:

  • Use isArrayKind instead of hasKindArray
  • Rename is PHI to isPHIKind for consistency
grosser marked an inline comment as not done.Dec 10 2015, 2:40 AM

Hi Michael,

thank your for your comments. The latest patch should address all your comments. Can you have a final look?

include/polly/ScopInfo.h
309

Changed.

600–602

Good idea.

696

I do not feel strong about this. Changed to isArrayKind.

grosser updated this revision to Diff 42403.Dec 10 2015, 2:46 AM
grosser marked an inline comment as not done.

Missed the hasKindValue -> isValueKind update

Meinersbur accepted this revision.Dec 10 2015, 4:11 AM
Meinersbur edited edge metadata.

Don't you want to wait for a third opinion?

include/polly/ScopInfo.h
144

llvm::Value %V is depicted below

174

Something seems to have gone wrong after clang-format

218

READs

696

Me neither; Code completion in Visual Studio will suggest isXXXKind when typing isKind.

This revision is now accepted and ready to land.Dec 10 2015, 4:11 AM
grosser updated this revision to Diff 42412.Dec 10 2015, 4:16 AM
grosser edited edge metadata.
  • Fix clang-format issue
  • READss

llvm::Value %V is depicted below

The sentence continues accross the picture, where there is also the relevant
'is' you are looking for.

Don't you want to wait for a third opinion?

Yes, I would appreciate a comment from someone else. Just wanted to make sure
you know I wanted to get still feedback on the final version.

jdoerfert accepted this revision.Dec 13 2015, 11:43 AM
jdoerfert edited edge metadata.

LGTM.

grosser closed this revision.Dec 13 2015, 12:03 PM

Committed in https://llvm.org/svn/llvm-project/polly/trunk@255467

(I forgot to add the phabricator review in the commit message)