This is an archive of the discontinued LLVM Phabricator instance.

[AlwaysInliner] Check inliner errors even without assserts
ClosedPublic

Authored by ellis on Mar 15 2022, 11:15 AM.

Details

Summary

When we build clang without asserts we should still check the result of
InlineFunction() to be sure there wasn't an error. Otherwise we could
incorrectly merge attributes in the next line.

This also removes a redundent call to getCaller().

Diff Detail

Event Timeline

ellis created this revision.Mar 15 2022, 11:15 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 15 2022, 11:15 AM
ellis published this revision for review.Mar 15 2022, 11:17 AM
ellis retitled this revision from Check inliner errors checked even without assserts to [AlwaysInliner] Check inliner errors even without assserts.
ellis added reviewers: kyulee, aeubanks, Carrot.
Herald added a project: Restricted Project. · View Herald TranscriptMar 15 2022, 11:17 AM

Essentially every unchecked assertion is followed by code that is effectively UB if the assertion should have failed but didn't run.
Why is this case so special that we should special-case it?

Essentially every unchecked assertion is followed by code that is effectively UB if the assertion should have failed but didn't run.
Why is this case so special that we should special-case it?

This is a pretty easy way to prevent unexpected behavior when inlining goes wrong with noasserts builds, i.e., production.

  1. Res gives a helpful error message that can be given to the user.
  2. The comment for InlineFunction() claims that the program will be fine if it failed to inline, so continuing is perfectly safe.

This returns false if it is not possible to inline this call. The program is still in a well defined state if this occurs though.

nikic requested changes to this revision.Mar 15 2022, 12:05 PM
nikic added a subscriber: nikic.

Either inlining always succeeds and we assert, or inlining can fail and we should never assert.

I do think that it can fail, and you should be able to add a test for it. There's a bunch of checks at the start of InlineFunction that should be usable for that purpose, e.g. a personality function mismatch.

This revision now requires changes to proceed.Mar 15 2022, 12:05 PM
ellis updated this revision to Diff 416034.Mar 16 2022, 5:34 PM

Add a test case for functions with the alwaysinline attribute that cannot be inlined and emit a remark instead of outputting directly to errs().

nikic accepted this revision.Mar 17 2022, 1:24 AM

LGTM

This revision is now accepted and ready to land.Mar 17 2022, 1:24 AM
This revision was landed with ongoing or failed builds.Mar 17 2022, 10:16 AM
This revision was automatically updated to reflect the committed changes.
kyulee added inline comments.Mar 17 2022, 10:29 AM
llvm/lib/Transforms/IPO/AlwaysInliner.cpp
81

Should it be moved down after InlineResult is successful?
This is about remarking a success case which we want only when it succeeded.

ellis added inline comments.Mar 17 2022, 1:15 PM
llvm/lib/Transforms/IPO/AlwaysInliner.cpp
81

Good catch. I've just uploaded D121946 to fix.