This is an archive of the discontinued LLVM Phabricator instance.

[Polly] [BlockGenerator] Unify ScalarMap and PhiOpsMap
ClosedPublic

Authored by grosser on Jan 19 2017, 7:09 AM.

Details

Summary

Instead of keeping two separate maps from Value to Allocas, one for
MemoryType::Value and the other for MemoryType::PHI, we introduce a single map
from ScopArrayInfo to the corresponding Alloca. This change is intended, both as
a general simplification and cleanup, but also to reduce our use of
MemoryAccess::getBaseAddr(). Moving away from using getBaseAddr() makes sure
we have only a single place where the array (and its base pointer) for which we
generate code for is specified, which means we can more easily introduce new
access functions that use a different ScopArrayInfo as base. We already today
experiment with modifiable access functions, so this change does not address
a specific bug, but it just reduces the scope one needs to reason about.

Another motivation for this patch is https://reviews.llvm.org/D28518, where
memory accesses with different base pointers could possibly be mapped to a
single ScopArrayInfo object. Such a mapping is currently not possible, as we
currently generate alloca instructions according to the base addresses of the
memory accesses, not according to the ScopArrayInfo object they belong to. By
making allocas ScopArrayInfo specific, a mapping to a single ScopArrayInfo
object will automatically mean that the same stack slot is used for these
arrays. For D28518 this is not a problem, as only MemoryType::Array objects are
mapping, but resolving this inconsistency will hopefully avoid confusion.

Event Timeline

grosser created this revision.Jan 19 2017, 7:09 AM
Meinersbur edited edge metadata.Jan 27 2017, 5:53 AM

I find it confusing that it is a ScalarMap, but its type is ArrayToAllocaMapTy. Our previous terminology was that a SAI (although it has Array in its name) is either a scalar or an array, according to MemoryKind. Proposal: SAIToAllocaMapTy (SaiAllocaMapTy?) or just AllocaMapTy.

I like the simplification of what was previously handled by different code paths.

include/polly/CodeGen/BlockGenerators.h
71–72

The name is ScalarMap, but it maps Arrays?

169–170

Suggestion:
For any llvm::Value, up to two different ScopArrayInfo objects are associated with it

Although this applies only to llvm::PHINode subtypes

179

And MemoryType::ExitPHI

lib/CodeGen/BlockGenerators.cpp
400

Proposal (to reduce indention avoid double lookup):

auto &Addr = ScalarMap[Array];
if (Addr)
  return Addr;

...
404–408

Remove braces?

Depends on out coding style, I am personally OK with braces here. We can also use the ternary operator or a table lookup here:

auto NameExt  = Table[Array->isPHIKind()];
407–408

I see this is what the old getOrCreateAlloca did as well. When I disable it, OpenMP\single_loop_with_param.ll fails. Presumbly this is used to use a thread parameter instead of a local scope variable.

Ideally, if we are not using the alloca anyway, we should not have created one. Possibly resolution by putting the ScopArrayInfo of this address to be replaced into ScalarMap instead into ScalarMap. GlobalMap should only contain "original llvm::Value -> generated llvm::Value", never "generated llvm::Value -> newer generated llvm::Value" which could cause transitivity issues (having to look up GlobalMap until no more replacement found)

410–413

You can use S.getScopArrayInfo to get the SAI; this imposed fewer requirements on the caller of this function.

grosser updated this revision to Diff 86135.Jan 27 2017, 3:14 PM

Address Michael's comments

grosser marked 6 inline comments as done.Jan 27 2017, 3:26 PM

Hi Michael,

all comments except the one that suggested a restructuring of how we handle OpenMP code. While your comments are well taken, I think these should be addressed in a separate cleanup patch, when time permits.

lib/CodeGen/BlockGenerators.cpp
400

I took this code snippet.

404–408

I dropped braces.

407–408

We may indeed use the outer alloca for a while, but will temporarily switch to an internal alloca while being in the OpenMP body. The OpenMP code should take care of copying values appropriately. Also, we do not have more than two levels of nesting, only normal + OpenMP. So, I do not think this is a bug here.

This could potentially be improved, but I believe such an improvement should be discussed separately. It will also require a more complete code review which I won't manage to do within the next week. I suggest to leave it as is for now.

410–413

Instead of dropping Array, I dropped Inst. This seems more clear in the calling context.

Meinersbur accepted this revision.Jan 27 2017, 3:53 PM
Meinersbur added inline comments.
lib/CodeGen/BlockGenerators.cpp
216

Is this dead code now?

374–375

This still looks strange; maybe add a comment what the lookup does? Could we do the GlobalMap lookup when Addr is inserted into ScalarMap (do lookup once instead of each time getOrCreateAlloca is called)?

402–405

Instead of introducing NewAddr you could write directly write to Addr since it's a reference to the already created entry.

411

Ok, I didn't think of doing it this way around.

This revision is now accepted and ready to land.Jan 27 2017, 3:53 PM

Just noted that you added comments while I was reviewing the updated diff.

grosser updated this revision to Diff 86166.Jan 27 2017, 11:40 PM
grosser marked 3 inline comments as done.

Address Michael's comments. Most importantly, add a large comment documenting
the somehow surprising use of GlobalMap.

Michael, can you have a final look if this comment is understandable?

grosser closed this revision.Jan 27 2017, 11:55 PM

This was (accidentally) already committed in r293374. I am still a little sleepy this morning and pushed ENTER at the wrong command line. As it was already complete from my side, I won't revert it, but please feel free to point out anything that I might have forgotten.

Meinersbur added inline comments.Jan 28 2017, 3:05 AM
include/polly/CodeGen/BlockGenerators.h
351

ScopArrayInfo

lib/CodeGen/BlockGenerators.cpp
387–388

Grammar: "at call to getOrCreateAlloca"?

The sentence is rather long, I had difficulty parsing it.

Thanks for the explanation.

402–405

What I meant was

Addr = new AllocaInst(Ty, ScalarBase->getName() + NameExt);
EntryBB = &Builder.GetInsertBlock()->getParent()->getEntryBlock();
Addr->insertBefore(&*EntryBB->getFirstInsertionPt());

Thank you. I added these changes in r293378.