This is an archive of the discontinued LLVM Phabricator instance.

[Polly] Introduce VirtualUse. NFC.
ClosedPublic

Authored by Meinersbur on Apr 28 2017, 5:21 PM.

Details

Summary

If a ScopStmt references a (scalar) value, there are multiple possibilities where this value can come. The decision about what kind of use it is must be handled consistently at different places, which can be error-prone. VirtualUse is meant to centralize the handling of the different types of value uses.

This patch makes ScopBuilder and CodeGeneration use VirtualUse. This already helps to show inconsistencies with the value handling. In order to keep this patch NFC, exceptions to the general rules are added. These might be fixed later if they turn to problems. Overall, this should result in fewer post-codegen IR-verification errors, but instead assertion failures in getNewValue that are closer to the actual error.

The "virtual" in VirtualUse/VirtualInstructions.h might be a misnomer as it currently has little to do with virtualizing instructions. I am open for other naming suggestions. The Virtual argument of VirtualUse::create is used to check the consistency of created MemoryAccesses, by the verifyUses function. The original intent to have Virtual in the name was that SCoP postprocessing-passes modify the accesses such that instructions are moved between ScopStmts. In order this to work, the BB an instruction resides in is less important.

For improving compile-time, caching the result of VirtualUse::create could be a possibility.

I started with using VirtualUse only for assertions. This unfortunately proved to be difficult as getNewValue as multiple returns and complete coverage.

Even if this is not committed, the study of inconsistencies of getNewValue could be useful.

Diff Detail

Repository
rL LLVM

Event Timeline

Meinersbur created this revision.Apr 28 2017, 5:21 PM
grosser accepted this revision.Apr 29 2017, 3:49 AM

Hi Michael,

thank you for the patch. It looks very good. I only added a couple of minor comments. Feel free to commit if you agree with them.

include/polly/Support/VirtualInstruction.h
25 ↗(On Diff #97175)

associated WITH

40 ↗(On Diff #97175)

double white space

81 ↗(On Diff #97175)

"an" -> "a" MemoryAccess.

101 ↗(On Diff #97175)

"any kind use": this sounds wrong. Do you just mean "for any use" or for "any kind of use within a statement"?

110 ↗(On Diff #97175)

us -> is

113 ↗(On Diff #97175)

Could you indent this?

lib/Analysis/ScopBuilder.cpp
576 ↗(On Diff #97175)

Can you transfer the comment from the old code:

"Do not create another MemoryAccess for reloading the value if one already exists."

644 ↗(On Diff #97175)

What is the invariant you verify here? Can you add a comment explaining it?

lib/CodeGen/BlockGenerators.cpp
136 ↗(On Diff #97175)

IS unnecessary

185 ↗(On Diff #97175)

Are they really pre-compute is it more that we already synthesized them once and consequently don't need to re-synthesize them again.

201 ↗(On Diff #97175)

My guess is that we code-generate load hoisted values like all other values by copying the instruction and adding the new return value to BBMap. We likely can skip code generation for load-hoisted values. This should solve the problem. It probably does not make sense to clean this up as part of this change. So just leaving this comment and assert and fixing this later seems to be the right strategy.

209 ↗(On Diff #97175)

Inter -> start with uppercase letter.

lib/Support/VirtualInstruction.cpp
79 ↗(On Diff #97175)

i.e., : Comma after "i.e."

This revision is now accepted and ready to land.Apr 29 2017, 3:49 AM
Meinersbur updated this revision to Diff 97832.May 4 2017, 8:30 AM
Meinersbur marked 11 inline comments as done.

Pre-commit update

Meinersbur added inline comments.May 4 2017, 8:33 AM
lib/CodeGen/BlockGenerators.cpp
185 ↗(On Diff #97175)

This "caching" seems unintentional because it happens only in 3 test cases.

If we want to cache already synthesized values, we should let SCEVExpander do it. SCEVExpander already has a map of already synthesized values. More importantly, it also caches intermediate values and does not necessarily put them into the current BB, but also into dominating BBs such that they values can be reused in multiple BBs.

That is, SCEVExpander could do caching more efficiently. Unfortunately. we create a new SCEVExpander object (in expandCodeFor) for each value we want to synthesize, so its cache is initalized empty.

This revision was automatically updated to reflect the committed changes.