This is an archive of the discontinued LLVM Phabricator instance.

[Polly] Merge IRAccess into MemoryAccess
ClosedPublic

Authored by Meinersbur on Sep 14 2015, 9:08 AM.

Details

Summary

All MemoryAccess objects will be owned by ScopInfo::AccFuncMap which previously stored the IRAccess objects. Instead of creating new MemoryAccess objects, the already created ones are reused, but their order might be different now. Some fields of IRAccess and MemoryAccess had the same meaning and are merged.

This is the last step of fusioning TempScopInfo.{h|cpp} and ScopInfo.{h.cpp}. Some refactoring might still make sense.

Diff Detail

Repository
rL LLVM

Event Timeline

Meinersbur updated this revision to Diff 34685.Sep 14 2015, 9:08 AM
Meinersbur retitled this revision from to [Polly] Merge IRAccess into MemoryAccess.
Meinersbur updated this object.
Meinersbur added reviewers: grosser, jdoerfert.
Meinersbur added a project: Restricted Project.
Meinersbur added subscribers: llvm-commits, pollydev.

but their order might be different now.

I always believed the order of (non-scalar) memory accesses in the SCoP
statement corresponded to the order of memory instructions in the basic
block. Was this true would not be anymore? If so I would like to keep the
old order if possible. If it wasn't true before, this comment is void.

Meinersbur updated this revision to Diff 34690.Sep 14 2015, 9:18 AM

rebase to r247572

but their order might be different now.

I always believed the order of (non-scalar) memory accesses in the SCoP
statement corresponded to the order of memory instructions in the basic
block. Was this true would not be anymore? If so I would like to keep the
old order if possible. If it wasn't true before, this comment is void.

I think the order is undefined. Former TempScopInfo added IRAccesses to AccFuncMap (apart from the Functions set in buildAccessFunctions) depending on the order of iteration through the BBs, which is I think also undefined (but deterministic). Also its name is AccFuncSetType, indicating that it was never intended to make order matter. If this is wring, it should be documented.

include/polly/ScopInfo.h
1479 ↗(On Diff #34685)

I was wondering why this is not always the case. Would save one parameter.

Meinersbur added a comment.

In http://reviews.llvm.org/D12843#245239, @llvm-commits wrote:

but their order might be different now.

I always believed the order of (non-scalar) memory accesses in the SCoP
statement corresponded to the order of memory instructions in the basic
block. Was this true would not be anymore? If so I would like to keep the
old order if possible. If it wasn't true before, this comment is void.

I think the order is undefined. Former TempScopInfo added IRAccesses to AccFuncMap (apart from the Functions set in buildAccessFunctions) depending on the order of iteration through the BBs, which is I think also undefined (but deterministic). Also its name is AccFuncSetType, indicating that it was never intended to make order matter. If this is wring, it should be documented.

Iterating over a BB has a defined order! I think we should not abandon
this for no good reason. At the latest the invariant hoisting patch will
make use of this (important for multiple ptr indirections).

Iterating over a BB has a defined order!

The iteration order of instructions in BB for sure matters, but I was talking about the order of BBs in a functions, which shouldn't influence the correctness of generated code (except the first BB which is defined as the entry; correct me if I am wrong).

I think we should not abandon
this for no good reason. At the latest the invariant hoisting patch will
make use of this (important for multiple ptr indirections).

To abandon something it must have been defined in the first place. From the code I do not see any pattern the code is trying to preserve except:

  1. Loads, stores, PHI reads and some scalar writes are consecutive
  2. Loads, stores, PHI reads and some scalar writes are in order as they appear in the BB.

Everything else depends on the order of BBs in a function.

Btw, the second property is preserved with this patch.

If you give me a definition of what the order is supposed to be, I can try to preserve it.

Meinersbur added a comment.
If you give me a definition of what the order is supposed to be, I can try to preserve it.

The order of non-scalar memory accesses in a statement should be the same as
the order of the corresponding memory access instructions in the BB. If
I understand you correctly that will not change, thus I'm good.

Same background on why the order change might be useful:

buildAccessFunctions() collected the IRAccess of those accesses (Loads, stores, PHI reads and some scalar writes) in a Functions list and appended it to the main list afterwards. Other accesses might have already been added to the main list from processing other BBs and the current BB. IRAccess was a copyable class, but after MemoryAccess has been merged in, it is not any more (because of the reference-counted ISL members), so it cannot be temporarily added to another list.

Hence, I removed the temporary list and add MemoryAccess objects directly to the main list. The order in which they are added to the main list remains the same, but other accessed might be added in between while iterating over the the same BB. This happened in the changed test case loop_carry.ll with the PHI %k.05 which has an incoming edge from the same BB "bb"for which the write is added.

include/polly/ScopInfo.h
96 ↗(On Diff #34690)

Maybe use a std::forward_list instead?

Rebase to r247970

This revision was automatically updated to reflect the committed changes.