This is an archive of the discontinued LLVM Phabricator instance.

Add option to CodeExtractor for hoisting static allocas with uses contained within extracted region
AbandonedPublic

Authored by rriddle on Jul 22 2016, 5:12 PM.

Details

Reviewers
davide
Summary

Give CodeExtractor the ability to hoist any static allocas that have all of their uses inside of the extracted region to be hoisted into the new function. Also changed the internal ValueSet of CodeExtractor to be a SmallVector to allow for the inputs and outputs to be modified after collection. This doesn't really change anything given that the inputs and outputs ValueSet are never used as a set after collection.

Diff Detail

Event Timeline

rriddle updated this revision to Diff 65197.Jul 22 2016, 5:12 PM
rriddle retitled this revision from to Add option to CodeExtractor for hoisting dominated static allocas.
rriddle updated this object.
rriddle added a reviewer: davide.
rriddle added a subscriber: llvm-commits.
rriddle updated this revision to Diff 65254.Jul 23 2016, 1:45 PM

Formatting

silvas added a subscriber: silvas.Jul 27 2016, 4:03 AM

A couple nits. Will look closer tomorrow.

We don't use the date convention on test cases anymore. You can just call the test case ExtractDominatedStaticAllocas.ll

/Users/rriddle/Desktop/llvm/llvm/lib/Transforms/Utils/CodeExtractor.cpp
728 ↗(On Diff #65254)

It's a bit unusual to have this extra space here on all the lines except the first (I noticed this in one of your other patches too).

730 ↗(On Diff #65254)

This can just be regular int or unsigned for the loop variable. Also, for whatever reason, the standard integer variables are i and e in LLVM even though otherwise our convention is for CamelCase variable names. I and E would be used for iterators however.

Also, even better, this can become a range-for loop.

Also, I'm not sure if you're using the terminology "static alloca" correct, as you seem to be using it to refer to simply constant size. An alloca must be in the entry block as well to be considered a static alloca:

/// isStaticAlloca - Return true if this alloca is in the entry block of the
/// function and is a constant size.  If so, the code generator will fold it
/// into the prolog/epilog code, so it is basically free.
bool isStaticAlloca() const;

Another quick comment.

/Users/rriddle/Desktop/llvm/llvm/lib/Transforms/Utils/CodeExtractor.cpp
732 ↗(On Diff #65254)

There seem to be very few uses of this pattern of const_cast combined with dyn_cast, and it smells a bit fishy to me. Is there some other preferred pattern in use in the codebase? Or is there another way to avoid the const_cast?

rriddle updated this revision to Diff 66274.Jul 31 2016, 8:13 PM
rriddle retitled this revision from Add option to CodeExtractor for hoisting dominated static allocas to Add option to CodeExtractor for hoisting static allocas with uses contained within extracted region.
rriddle updated this object.

Updated to reflect Sean's comments

davide edited edge metadata.Dec 14 2016, 9:01 PM

Some comments online. Also please clang-format this patch.

lib/Transforms/IPO/PartialInlining.cpp
138–139

is this clang-formatted?

lib/Transforms/Utils/CodeExtractor.cpp
176–177

this needs a comment.

180–187

Can you add a test exercising this behaviour?

189–193

same.

s/online/inline/

rriddle abandoned this revision.Dec 15 2016, 3:48 AM