This is an archive of the discontinued LLVM Phabricator instance.

[PartialInlining] Use isInlineViable to detect constructs preventing inlining.
ClosedPublic

Authored by fhahn on Feb 2 2018, 7:59 AM.

Details

Summary

Use isInlineViable to prevent inlining of functions with non-inlinable
constructs, in case cost analysis is skipped.

Diff Detail

Repository
rL LLVM

Event Timeline

fhahn created this revision.Feb 2 2018, 7:59 AM

isInlineViable doesn't care whether the code is actually reachable, so you could pessimize partial inlining in certain cases, e.g. a function which calls va_start conditionally. I don't think we need fix that now, but it would be nice to at least have a testcase demonstrating the issue.

isInlineViable doesn't care whether the code is actually reachable, so you could pessimize partial inlining in certain cases, e.g. a function which calls va_start conditionally. I don't think we need fix that now, but it would be nice to at least have a testcase demonstrating the issue.

Thanks Eli, I will try to come up with a test case tomorrow.

fhahn added a comment.Feb 14 2018, 7:27 AM

I could not find a case where not considering reachability would prevent us from partial inlining with this patch.

Currently, CodeExtractor won't extract unreachable blocks (via DT), blocks with vastart/vaend or blockaddresses in the function we use for partial inlining. That only leaves localescape which isInlineViable prevents, and those calls always have to be in the entry block, so they are always reachable. I think it would be better to avoid extracting blocks with localesacpe calls for now and just assert isInlineViable.

If we teach CodeExtractor to consider reachability beyond using the dominator tree, we should consider the same reachability in isInlineViable.

Independent of this patch, considering reachability in isInlineViable could be beneficial for alwaysinline functions, but that should be an independent patch I think. What do you think @efriedma , does this make sense?

Can you explain the difference between llvm::isInlineViable and CodeExtractor::isBlockValidForExtraction? I'm kind of confused why they're checking different things.

fhahn added a comment.Feb 14 2018, 2:35 PM

Can you explain the difference between llvm::isInlineViable and CodeExtractor::isBlockValidForExtraction? I'm kind of confused why they're checking different things.

I think CodeExtractor is not only used to extract code for partial inlining, but also used by LoopExtractor. I suppose this is why they do not check the same thing, but I think it would make sense to check for non-inlinable blocks in CodeExtractor too. Maybe we should add an isInlineableBlock function and use them in isBlockValidForExtraction?

It would be good to clean them up to make it clear exactly how they differ, yes.

fhahn updated this revision to Diff 136746.Mar 2 2018, 7:19 AM
fhahn edited the summary of this revision. (Show Details)

Update to use isInlineViable only when cost analysis is skipped.

I think CodeExtractor is not only used to extract code for partial inlining, but also used by LoopExtractor. I suppose this is why they do not check the same thing, but I think it would make sense to check for non-inlinable blocks in CodeExtractor too. Maybe we should add an isInlineableBlock function and use them in isBlockValidForExtraction?

After having another look, the difference between isBlockValidForExtraction and isInlineViable is that isBlockValidForExtraction checks loops that are going to be outlined, rather than inlined.

efriedma accepted this revision.Mar 9 2018, 2:25 PM

LGTM

This revision is now accepted and ready to land.Mar 9 2018, 2:25 PM
This revision was automatically updated to reflect the committed changes.