This updates the Inliner to only add a single Optimization
Remark when Inlining, rather than an Analysis Remark and an
Optimization Remark.
Details
Diff Detail
- Build Status
Buildable 8738 Build 8738: arc lint + arc unit
Event Timeline
lib/Transforms/IPO/Inliner.cpp | ||
---|---|---|
557 | I'm not sure of the overhead of re-computing the InlineCost, which is used below. Maybe I should also return it (using an output parameter) from shouldInline above? |
lib/Transforms/IPO/Inliner.cpp | ||
---|---|---|
557 | Yes, that is what I was thinking of doing. |
lib/Transforms/IPO/Inliner.cpp | ||
---|---|---|
557 | Ok, I will update the patch to do so. |
Update shouldInline in Inliner to return the InlineCost, rather
than recomputing the cost.
I had to be a little hack-y around TotalSecondaryCost, but
I couldn't see a better way to do that.
Also I added a getThreshold() method to InlineCost for use in
messages, rather than reversing how getCostDelta() is calculated.
lib/Transforms/IPO/Inliner.cpp | ||
---|---|---|
387–389 | I am fine with this. Alternatively we could change the return type to Optional<InlineCost> and return None here and check (!IC || !*IC) in the caller but that seems like an overkill. | |
574–585 | No {} around a single statement. | |
875–878 | Isn't this the path via the new PM? Don't you need to emit the remarks for the successful inlining here as well? Should probably add a test for this if I am right ;). |
Thanks for that review, I'll get onto doing the changes you've asked for.
lib/Transforms/IPO/Inliner.cpp | ||
---|---|---|
387–389 | I think Optional<InlineCost> might be a better solution than a magic value that happens to do what we want. I'll see what changing to that does. | |
574–585 | Sure. I thought I had run clang-format, but it evidently didn't catch this. I'll do it manually. | |
875–878 | Ok, I didn't understand why there were two implementations, one for each pass makes more sense. I need to fix that bug with the path option, which might need to land first, so that tests start failing. |
Address review feedback.
Using Optional<InlineCost> seemed to be a good compromise,
so I have used it.
I also am now emitting more optimisation remarks in the new
pass.
LGTM. Are you going to commit this as is or fix the new PM -pass-remarks-output first and update this? I am fine either way.
I think I'm going to pause on this patch for a moment until the other is accepted and committed.
I think I have that fix (as far as code is concerned), but I think that patch should include updating all tests that currently only use the old pass manager to emit remark yaml files to also make them do exactly the same with the new pass manager, and that will take a little longer. Expect the complete patch of both code and tests some time over the weekend, I think.
Add Tests that use NewPM
The only issue here is that the NewPM's inline pass does not emit remarks that say "foo will not be inlined into bar because its definition is unavailable", which seems to be to do with how the inline pass finds candidates to inline (the queue it uses never even admits declaration-only functions). I'm not sure this is a major problem per se, but we should perhaps look at re-adding this functionality later.
This caused some clang and lld build failures.
I've reverted the commit in https://reviews.llvm.org/rL311274 so we can fix tests and look at re-applying it later.
Ok, I have patches for the two other repositories which had failing tests.
I have no idea how to make these all land at the same time, but roughly the same time is ok too, I think.
LGTM. Are you going to commit this as is or fix the new PM -pass-remarks-output first and update this? I am fine either way.
Yep, just be prepared to see bot failures if an intermittent version is picked up by a bot.
The New PM pass remarks output fix landed on Saturday, and I updated these tests to use the NewPM too (see the diffs to test/Trasforms/Inline/optimization*).
Yeah, intermittent but expected failures I can cope with, unexpected ones are less fun.
Don't we have a ctor that converts from T? I.e. can't you just say return IC?