Clang: Add a new flag Wmisnoinline for printing hot noinline functions

[iamarchit123]

Summary

In lieu of the change D115907 which introduces a new warning Wmisnoexpect, I introduce a new warning, Wmisnoinline to print potential wrong usage of noinline attribute with functions. NoInline functions should ideally not be hot as per profile summary. If they are hot, we could print a warning to inform user to think again about marking of their annotation as it may happen that maybe, overtime functions which a user might think is cold/slow may turn hot and compiler may benefit from inlining them.

The WMisNoInline only works if profile data is attached or else throws a warning and has no effect. It emits a warning if the following two conditions are met:

1. If a noinline function is hotter than fdiagnostics-misnoinline-percentile-threshold (by default set to 99%) as per PSI analysis.
2. There was a possibility of Inlining that function in CGSCC Inliner pass(based on cost-threshold calculation).

The change was tested on HHVM and we found out 14 extremely hot noinline functions which were within 50 percentile hotness and ~110 mildly hot noinline functions within 99 percentile hotness based on PSI analysis.

Test Plan: ninja check all
llvm-lit --show-all MisNoInline.cpp
llvm-lit --show-all MisNoInline_LowThreshold.cpp
llvm-lit --show-all MisNoInline.ll

[iamarchit123]

update commit

[paulkirth]

Hi, thanks for taking a look at this. Before we start an in-depth review, can you describe the deficiencies w/ the existing diagnostics, and why they don't meet your needs?

Primarily, I'm a little skeptical if taking the same approach as MisExpect is the correct approach.

1. Unlike llvm.expect, the noinline attribute is often used for correctness. I'm not sure it makes sense to warn about it in the same way as a performance optimization. My experience may differ from the code bases you work in, but I cannot recall seeing a function annotated noinline for due to any kind of performance reason. The one exception I can think of being code marked as cold for outlining purposes, but those are usually inferred from profiles or are added due to other annotations. Do people do this for better i-cache performance or something?
2. MisExpect diagnostics need to run a specific points during compilation to check the weights added by the llvm.expect intrinsic against the profile, so it can't be a separate pass, since e.g., LowerExpectIntrinsicPass and the PGO passes for instrumentation/sampling replace/remove that information. From what I can see this could be its own analysis pass, since you at most need to consult the function entry count.
3. Optimization remarks already exist for missed inlining opportunities. I'm unsure of the value in using a warning over the existing diagnostic in this case. In the case of llvm.expect intrinsics, it may be the result of an incorrect annotation, or a mis-annotated branch (i.e., marking a branch w/ LIKELY instead of UNLIKELY). In these cases, we'd like to signal to users a problem w/ the source code/annotation. I'm not sure that the same is true for noinline attributes. Is this something you want to use to fail builds? That was something we wanted to achieve for Fuchsia's CI, which is why -Wmisexpect exists as more than an optimization remark.

[iamarchit123]

In D132186#3741210, @paulkirth wrote:

Hi, thanks for taking a look at this. Before we start an in-depth review, can you describe the deficiencies w/ the existing diagnostics, and why they don't meet your needs?

Primarily, I'm a little skeptical if taking the same approach as MisExpect is the correct approach.

Unlike llvm.expect, the noinline attribute is often used for correctness. I'm not sure it makes sense to warn about it in the same way as performance optimization. My experience may differ from the code bases you work in, but I cannot recall seeing a function annotated noinline for due to any kind of performance reason. The one exception I can think of being code marked as cold for outlining purposes, but those are usually inferred from profiles or are added due to other annotations. Do people do this for better i-cache performance or something?

I was under the impression that it was used for performance reasons and hot functions should not ideally be marked noinline. @modimo could you also pitch in on this? If not function entry count what other things could possibly indicate a false usage of noinline(if not the hotness)

MisExpect diagnostics need to run a specific points during compilation to check the weights added by the llvm.expect intrinsic against the profile, so it can't be a separate pass, since e.g., LowerExpectIntrinsicPass and the PGO passes for instrumentation/sampling replace/remove that information. From what I can see this could be its own analysis pass, since you at most need to consult the function entry count.

This can be a separate pass but even I am using Cost Analysis to check noinline functions cost apart from function entry count, so it felt natural to integrate the noinline warning into inline cost analysis.

Optimization remarks already exist for missed inlining opportunities. I'm unsure of the value in using a warning over the existing diagnostic in this case. In the case of llvm.expect intrinsics, it may be the result of an incorrect annotation, or a mis-annotated branch (i.e., marking a branch w/ LIKELY instead of UNLIKELY). In these cases, we'd like to signal to users a problem w/ the source code/annotation. I'm not sure that the same is true for noinline attributes. Is this something you want to use to fail builds? That was something we wanted to achieve for Fuchsia's CI, which is why -Wmisexpect exists as more than an optimization remark.

I think there is no Optimization remark emission for missed inlining opportunities for noinline functions as cost analysis is skipped for functions marked with noinline attribute. No we don't want any builds to fail with this. Our only aim to make this change is to emit a warning for functions which a user may have accidentally marked noinline but removing noinline attribute may give some performance benefits.

@modimo feel free to pitch in as well on this about concerns raised by @paulkirth and any changes I could make on this based on the comments.

[paulkirth]

To be clear, I'm not morally opposed to your patch, I just wanted to understand the context more completely and why this is the best approach. And like I said, I can't recall encountering a place where noinline was done for performance reasons. Code size and correctness are the two reasons I've seen commonly though.

In D132186#3750450, @iamarchit123 wrote:

I was under the impression that it was used for performance reasons and hot functions should not ideally be marked noinline. @modimo could you also pitch in on this? If not function entry count what other things could possibly indicate a false usage of noinline(if not the hotness)

Using the entry count isn't the issue, its that people don't normally mark their hot code noinline, certainly not w/o a reason. I'm open to the idea that there might be a performance reason to do so, but I'm aware of other reasons that are more common in my experience. While you've gotten good use from the diagnostic, I'm unsure how well that generalizes.

This can be a separate pass but even I am using Cost Analysis to check noinline functions cost apart from function entry count, so it felt natural to integrate the noinline warning into inline cost analysis.

If the goal is to disclose that the annotation may be wrong, then shouldn't you want to report that regardless of the cost analysis? The inliner's decision is orthogonal to whether the attribute is beneficial or potentially incorrect, right?

I think there is no Optimization remark emission for missed inlining opportunities for noinline functions as cost analysis is skipped for functions marked with noinline attribute.

Right, but your new diagnostic seems to be exactly like those remarks, which is why I brought them up. You are issuing a diagnostic regarding a missed inlining opportunity afterall, so I don't think its strange to suggest that you should consider reporting these through the same mechanism. If there's a good reason not to, that's fine, but then I would expect there to be some rationale.

No we don't want any builds to fail with this. Our only aim to make this change is to emit a warning for functions which a user may have accidentally marked noinline but removing noinline attribute may give some performance benefits.

Then using a remark seems to be the better choice. There are lot's of places that compile w/ -Werror, and making this a warning ensures builds fail. That was a goal for Fuchsia w/ MisExpect, so if it's not in this case, you may want to consider only using remarks as an alternative, since they are always only informational.

Like I said before, I'm not opposed to this, but I'd like to understand why the current infrastructure and diagnostics are insufficient or shouldn't just be updated to also report this case. My other concern is that there are significantly more cases where noinline is used for correctness than there are for performance reasons, which may dilute the usefulness of the diagnostic.

[iamarchit123]

@paulkirth this change was done under the intuition that marking hot functions noinline may hurt performance. This change till now hasn't been tested for performance improvements and so the points that you raise that functions marked noinline are marked not for hotness/performance but rather correctness is something that I was unaware of. Since I don't have access to big services currently and can't test this change, so I may be unable to defend this change. @modimo feel free if you think folks can come back and test this change for effectiveness or completely redo this if the above change is still insufficient.

I agree until it's shown/proven that there is a serious performance win this change may not be useful. Thanks for the review.

[tejohnson]

In D132186#3750925, @iamarchit123 wrote:

@paulkirth this change was done under the intuition that marking hot functions noinline may hurt performance. This change till now hasn't been tested for performance improvements and so the points that you raise that functions marked noinline are marked not for hotness/performance but rather correctness is something that I was unaware of. Since I don't have access to big services currently and can't test this change, so I may be unable to defend this change. @modimo feel free if you think folks can come back and test this change for effectiveness or completely redo this if the above change is still insufficient.

I agree until it's shown/proven that there is a serious performance win this change may not be useful. Thanks for the review.

I have seen a few cases where noinline was used for performance, in addition to other cases like avoiding too much stack growth. I've also seen it used without any comment whatsoever. So I think it would be good to make it easier to identify cases where we are blocked from inlining at hot callsites because of the attribute.

It is a little different than misexpect though in that the expect hints are pretty much only for performance, so it is more useful to be able to issue a strong warning that can be turned into an error if they are wrong. And also there was no way to report the misuse of expects earlier, unlike inlining where we already had the remarks plumbing.

I haven't looked through the patch in detail, but is it possible to use your changes to emit a better missed opt remark from the inliner for these cases (I assume we will already emit a -Rpass-missed=inline for the noinline attribute case, just not highlighting that it is hot and would have been inlined for performance reasons otherwise)? I suppose one main reason for adding a warning is that the missed inline remarks can be really noisy and not really useful to the user vs a compiler optimization engineer doing inliner/compiler tuning, and therefore a warning would make it easier to turn on more widely as user feedback that can/should be addressed in user code.

[paulkirth]

In D132186#3751985, @tejohnson wrote:

I have seen a few cases where noinline was used for performance, in addition to other cases like avoiding too much stack growth.

Well, I stand corrected. I'm curious about what these cases are, but in any case if there are cases where its done, then I agree that a diagnostic would be helpful.

I've also seen it used without any comment whatsoever. So I think it would be good to make it easier to identify cases where we are blocked from inlining at hot callsites because of the attribute.

I wonder if there is some analysis or heuristic we could use to distinguish those cases? Nothing really comes to mind, but it would be nice if we had one.

It is a little different than misexpect though in that the expect hints are pretty much only for performance, so it is more useful to be able to issue a strong warning that can be turned into an error if they are wrong. And also there was no way to report the misuse of expects earlier, unlike inlining where we already had the remarks plumbing.

I haven't looked through the patch in detail, but is it possible to use your changes to emit a better missed opt remark from the inliner for these cases (I assume we will already emit a -Rpass-missed=inline for the noinline attribute case, just not highlighting that it is hot and would have been inlined for performance reasons otherwise)? I suppose one main reason for adding a warning is that the missed inline remarks can be really noisy and not really useful to the user vs a compiler optimization engineer doing inliner/compiler tuning, and therefore a warning would make it easier to turn on more widely as user feedback that can/should be addressed in user code.

Yeah, I was thinking we could emit a new remark type for this to differentiate, but it seems simpler more user friendly to emit some clar diagnostic directly.

I think we’re starting to accumulate a few of these diagnostics now that are trying to diagnose potential performance deficiencies based on profiling information. Originally we had prototyped a tool for misexpect based on libtooling that ran over the build based on the compile commands DB and reported everything it found. I wonder if reviving that would be useful in these cases when you want to look for performance issues like this, misexpect, and other cases? Making ORE diagnostic output queryable through a tool may also be a good option, but I'm not too familiar with what already exists in that area.

[modimo]

Thanks for taking a look!

In D132186#3752150, @paulkirth wrote:

In D132186#3751985, @tejohnson wrote:

I have seen a few cases where noinline was used for performance, in addition to other cases like avoiding too much stack growth.

Well, I stand corrected. I'm curious about what these cases are, but in any case if there are cases where its done, then I agree that a diagnostic would be helpful.

Same. The instances I've seen is an older codebase where compiler optimizations were not as powerful and/or purposefully written by engineers that didn't trust the compiler to do the right thing.

It is a little different than misexpect though in that the expect hints are pretty much only for performance, so it is more useful to be able to issue a strong warning that can be turned into an error if they are wrong. And also there was no way to report the misuse of expects earlier, unlike inlining where we already had the remarks plumbing.

I haven't looked through the patch in detail, but is it possible to use your changes to emit a better missed opt remark from the inliner for these cases (I assume we will already emit a -Rpass-missed=inline for the noinline attribute case, just not highlighting that it is hot and would have been inlined for performance reasons otherwise)? I suppose one main reason for adding a warning is that the missed inline remarks can be really noisy and not really useful to the user vs a compiler optimization engineer doing inliner/compiler tuning, and therefore a warning would make it easier to turn on more widely as user feedback that can/should be addressed in user code.

Yeah, I was thinking we could emit a new remark type for this to differentiate, but it seems simpler more user friendly to emit some clar diagnostic directly.

I think we’re starting to accumulate a few of these diagnostics now that are trying to diagnose potential performance deficiencies based on profiling information. Originally we had prototyped a tool for misexpect based on libtooling that ran over the build based on the compile commands DB and reported everything it found. I wonder if reviving that would be useful in these cases when you want to look for performance issues like this, misexpect, and other cases? Making ORE diagnostic output queryable through a tool may also be a good option, but I'm not too familiar with what already exists in that area.

Currently a new ORE (-pass-remarks=misnoinline) is getting generated, which misnoexcept also does. Agreed a warning is more familiar and friendlier for users so I lean towards that approach. For additional tooling, I think the first step will be to trial this on more real programs to see what cases are interesting. @iamarchit123 just finished his internship with us so I'll be evaluating these changes on HHVM to see if they can swing the performance needle.

[paulkirth]

In D132186#3752403, @modimo wrote:

Same. The instances I've seen is an older codebase where compiler optimizations were not as powerful and/or purposefully written by engineers that didn't trust the compiler to do the right thing.

Thanks for pointing that out. I had failed to consider those scenarios. I do recall having discussions w/ hardware/embedded engineers a long time ago regarding their mistrust of the compiler, so I should have thought about these types of situations.

Currently a new ORE (-pass-remarks=misnoinline) is getting generated, which misnoexcept also does. Agreed a warning is more familiar and friendlier for users so I lean towards that approach. For additional tooling, I think the first step will be to trial this on more real programs to see what cases are interesting. @iamarchit123 just finished his internship with us so I'll be evaluating these changes on HHVM to see if they can swing the performance needle.

@iamarchit123, thanks for your contribution, and I hope your summer went well! You may want to see if you can present your work at the dev meeting in November. Even a lighting talk is a great item for a resume. There's even a student travel grant to help out w/ costs. https://discourse.llvm.org/t/llvm-foundation-student-travel-grants-available-sept-8-deadline/64794. Also, universities often have their own travel grants for students presenting at a conference, so I would encourage you to see if you're eligible for one of those from your own university too.

@modimo Keep us posted w/ your findings from HHVM, it will be interesting to see what kind of improvements can be gained.

llvm/docs/MisNoInline.rst

2

9–39

This is almost a verbatim copy of the MisExpect.rst. If these diagnostics are so similar, and use the exact same methodology, then maybe we should unify them as something like Profile-based Mis-annotation Analysis? We can describe the basic approach and then in subsections describe how individual diagnostics work/differ. What do you think?

llvm/include/llvm/Analysis/InlineCost.h

174

Do you need this variable? you store it here in the InlineCost, but the only place its used is in canEmitNoInlineWarning. Seems easier to just check for Attribute::NoInline on the Callee variable directly in canEmitNoInlineWarning, and avoid plumbing all this data around.

llvm/lib/Analysis/InlineAdvisor.cpp

69–71

the verbage here makes noinline sound like its always bad/wrong. Maybe "... noinlne function attribute on hot functions, which may degrade performance"?

148–150

nit: Maybe sink these until they're needed?

163

why not check for NoInline on either CB or Callee directly?

166–169

Seems like a helper function would make this a little cleaner/ergonomic.

233–242

Can we separate this out into its own function? or maybe it makes more sense to be part of getInlineCost? If it were there, then you may avoid invoking isInlineViableFromCostAnalysis more than necessary, right?

also, neither Callee nor CalleeTTI have changed from their def above, so do we need to shadow them here?

[iamarchit123]

Hi @modimo @paulkirth any good open source benchmarks where I also can test this? The problem is finding some standard benchmarks which are profiled as well as have good performance measuring metric to measure improvement.

[paulkirth]

@iamarchit123 I think the standard advice is to start w/ the llvm-test-suite and then explore other benchmarks as needed. Also, Clang itself is often a very good starting point.

As for profiles, it probably won't be representative, but you could collect the profile using your benchmark and then assess how often the mismatch w/ inlining happens. if you want to do it w/ Clang itself, then a common approach I've heard is to record have Clang build your project and then use ninja trace or equivalent to find the 5-10 TUs w/ the longest compile time. Then stick them in the https://github.com/llvm/llvm-project/tree/main/clang/utils/perf-training directory, which will use them for PGO automatically. If you go that route, you may need to preprocess the source files.

[modimo]

In D132186#3802989, @paulkirth wrote:

@iamarchit123 I think the standard advice is to start w/ the llvm-test-suite and then explore other benchmarks as needed. Also, Clang itself is often a very good starting point.

As for profiles, it probably won't be representative, but you could collect the profile using your benchmark and then assess how often the mismatch w/ inlining happens. if you want to do it w/ Clang itself, then a common approach I've heard is to record have Clang build your project and then use ninja trace or equivalent to find the 5-10 TUs w/ the longest compile time. Then stick them in the https://github.com/llvm/llvm-project/tree/main/clang/utils/perf-training directory, which will use them for PGO automatically. If you go that route, you may need to preprocess the source files.

+1 Clang is the best starting point. I've been busy recently so haven't had a chance to run the HHVM experiments, starting a run today. Paul left some good review comments that you can address without requiring performance runs--I would recommend getting the patch updated so when the results come back everything will be ready to commit.

clang/docs/MisNoInline.rst

+===================
+Misnoinline
+===================
+.. contents::
+
+.. toctree::
+   :maxdepth: 1
+
+When developers use noinline attribute with a function, i.e., through use of
+``__attribute__((noinline))``, they are trying to communicate that the
+function should not be inlined by the compiler. These can be due to various
+number of reasons to mark a function noinline. If a function is small,
+not critical to the performance of your code and would be called less often,
+especially in cases of error handling, it makes sense to noinline a function.
+These annotations, however, can be incorrect for a variety of reasons:
+changes to the code base may make these functions hot, the developer
+mis-annotated them, or perhaps they assumed something incorrectly when they
+wrote the annotation. Regardless of why, it is useful to detect these
+situations so that the user can rethink and remove the attribute as necessary.
+
+MisNoInline diagnostics are intended to help developers identify and address
+these situations, by comparing function hotness of noinline function and
+checking if they indeed were candidates to become inline. Whenever percentile values
+are breached, a warning is emitted from backend. Details on how the flags operate
+in the LLVM backed can be found in LLVM's documentation.
+
+By default, MisNoInline checking is quite linient. It checks on default threshold percentile
+of 99%. Because this may emit a lot of warnings, MisNoInline diagnostics are not enabled by
+default, and support an additional flag to decrease the noinline percentile threshold and filter
+hotter functions. The ``-fdiagnostics-misnoinline-percentile-threshold=N`` accepts
+function entry percentile coldness upto N before emitting a warning. So passing
+``-fdiagnostics-misnoinline-percentile-threshold=50`` will not report diagnostic messages
+if the noinline function's hotness is greater than 50% as per PSI analysis.
+
+MisNoInline diagnostics are also available in the form of optimization remarks,
+which can be serialized and processed through the ``opt-viewer.py``
+scripts in LLVM.
+
+.. option:: -Rpass=misnoinline
+
+  Enables optimization remarks for misnoinline when profiling data conflicts with
+  use of ``noinline`` attribute.
+
+
+.. option:: -Wmisnoinline
+
+  Enables misnoinline warnings when profiling data conflicts with use of
+  ``noinline`` attribute.
+
+.. option:: -fdiagnostics-misnoinline-percentile-threshold=N
+
+  Relaxes misnoinline checking to not emit warning for functions colder than N%.
+
+LLVM supports 4 types of profile formats: Frontend, IR, CS-IR, and
+Sampling. MisNoInline Diagnostics are compatible with all Profiling formats.
+
++----------------+--------------------------------------------------------------------------------------+
+| Profile Type   | Description                                                                          |
++================+======================================================================================+
+| Frontend       | Profiling instrumentation added during compilation by the frontend, i.e. ``clang``   |
++----------------+--------------------------------------------------------------------------------------+
+| IR             | Profiling instrumentation added during by the LLVM backend                           |
++----------------+--------------------------------------------------------------------------------------+
+| CS-IR          | Context Sensitive IR based profiles                                                  |
++----------------+--------------------------------------------------------------------------------------+
+| Sampling       | Profiles collected through sampling with external tools, such as ``perf`` on Linux   |
++----------------+--------------------------------------------------------------------------------------+

clang/docs/ReleaseNotes.rst

- ``-Wbitfield-constant-conversion`` now diagnoses implicit truncation when 1 is
   `Issue 53253 <https://github.com/llvm/llvm-project/issues/53253>`_.
 - ``-Wincompatible-function-pointer-types`` now defaults to an error in all C
   language modes. It may be downgraded to a warning with
   ``-Wno-error=incompatible-function-pointer-types`` or disabled entirely with
   ``-Wno-implicit-function-pointer-types``.
 - Clang will now print more information about failed static assertions. In
   particular, simple static assertion expressions are evaluated to their
   compile-time value and printed out if the assertion fails.
+- ``-Wmisnoinline`` warns when the noinline attribute attached to the function
+  may look wrong compared to profiling data.
 
 Non-comprehensive list of changes in this release
 -------------------------------------------------
 
 New Compiler Flags
 ------------------
 
 Deprecated Compiler Flags

clang/include/clang/Basic/CodeGenOptions.h

public:
   ///
   /// If threshold option is not specified, it is disabled by default.
   Optional<uint64_t> DiagnosticsHotnessThreshold = 0;
 
   /// The maximum percentage profiling weights can deviate from the expected
   /// values in order to be included in misexpect diagnostics.
   Optional<uint32_t> DiagnosticsMisExpectTolerance = 0;
 
+  /// The minimum function hotness percentile after which we emit
+  /// a warning to be included in misnoinline diagnostics.
+  Optional<uint64_t> DiagnosticsNoInlinePercentileThreshold = 990000;
+
 public:
   // Define accessors/mutators for code generation options of enumeration type.
 #define CODEGENOPT(Name, Bits, Default)
 #define ENUM_CODEGENOPT(Name, Type, Bits, Default) \
   Type get##Name() const { return static_cast<Type>(Name); } \
   void set##Name(Type Value) { Name = static_cast<unsigned>(Value); }
 #include "clang/Basic/CodeGenOptions.def"
 

clang/include/clang/Basic/CodeGenOptions.def

 CODEGENOPT(NoCommon          , 1, 0) ///< Set when -fno-common or C++ is enabled.
 CODEGENOPT(NoDwarfDirectoryAsm , 1, 0) ///< Set when -fno-dwarf-directory-asm is
                                        ///< enabled.
 CODEGENOPT(NoExecStack       , 1, 0) ///< Set when -Wa,--noexecstack is enabled.
 CODEGENOPT(FatalWarnings     , 1, 0) ///< Set when -Wa,--fatal-warnings is
                                      ///< enabled.
 CODEGENOPT(NoWarn            , 1, 0) ///< Set when -Wa,--no-warn is enabled.
 CODEGENOPT(MisExpect         , 1, 0) ///< Set when -Wmisexpect is enabled
+CODEGENOPT(MisNoInline       , 1, 0) ///< Set when -Wmisnoinline is enabled
 CODEGENOPT(EnableSegmentedStacks , 1, 0) ///< Set when -fsplit-stack is enabled.
 CODEGENOPT(NoInlineLineTables, 1, 0) ///< Whether debug info should contain
                                      ///< inline line tables.
 CODEGENOPT(StackClashProtector, 1, 0) ///< Set when -fstack-clash-protection is enabled.
 CODEGENOPT(NoImplicitFloat   , 1, 0) ///< Set when -mno-implicit-float is enabled.
 CODEGENOPT(NullPointerIsValid , 1, 0) ///< Assume Null pointer deference is defined.
 CODEGENOPT(OpenCLCorrectlyRoundedDivSqrt, 1, 0) ///< -cl-fp32-correctly-rounded-divide-sqrt
 CODEGENOPT(HIPCorrectlyRoundedDivSqrt, 1, 1) ///< -fno-hip-fp32-correctly-rounded-divide-sqrt

clang/include/clang/Basic/DiagnosticDriverKinds.td

 def err_drv_command_failure : Error<
   "unable to execute command: %0">;
 def err_drv_invalid_darwin_version : Error<
   "invalid Darwin version number: %0">;
 def err_drv_invalid_diagnotics_hotness_threshold : Error<
   "invalid argument in '%0', only integer or 'auto' is supported">;
 def err_drv_invalid_diagnotics_misexpect_tolerance : Error<
   "invalid argument in '%0', only integers are supported">;
+def err_drv_invalid_diagnotics_misnoinline_threshold : Error<
+  "invalid argument in '%0' only integers are supported">;
 def err_drv_missing_argument : Error<
   "argument to '%0' is missing (expected %1 value%s1)">;
 def err_drv_invalid_Xarch_argument_with_args : Error<
   "invalid Xarch argument: '%0', options requiring arguments are unsupported">;
 def err_drv_Xopenmp_target_missing_triple : Error<
   "cannot deduce implicit triple value for -Xopenmp-target, specify triple using -Xopenmp-target=<triple>">;
 def err_drv_invalid_Xopenmp_target_with_args : Error<
   "invalid -Xopenmp-target argument: '%0', options requiring arguments are unsupported">;

clang/include/clang/Basic/DiagnosticFrontendKinds.td

 def warn_profile_data_unprofiled : Warning<
   "no profile data available for file \"%0\"">,
   InGroup<ProfileInstrUnprofiled>;
 def warn_profile_data_misexpect : Warning<
   "Potential performance regression from use of __builtin_expect(): "
   "Annotation was correct on %0 of profiled executions.">,
   BackendInfo,
   InGroup<MisExpect>;
+def warn_profile_data_misnoinline : Warning<
+  "noinline attribute marking for %0:%1 may hurt performance.">,
+  BackendInfo,
+  InGroup<MisNoInline>;
 } // end of instrumentation issue category
 
 }

clang/include/clang/Basic/DiagnosticGroups.td

 def BackendOptimizationFailure : DiagGroup<"pass-failed">;
 def BackendWarningAttributes : DiagGroup<"attribute-warning">;
 
 // Instrumentation based profiling warnings.
 def ProfileInstrMissing : DiagGroup<"profile-instr-missing">;
 def ProfileInstrOutOfDate : DiagGroup<"profile-instr-out-of-date">;
 def ProfileInstrUnprofiled : DiagGroup<"profile-instr-unprofiled">;
 def MisExpect : DiagGroup<"misexpect">;
+def MisNoInline : DiagGroup<"misnoinline">;
 
 // AddressSanitizer frontend instrumentation remarks.
 def SanitizeAddressRemarks : DiagGroup<"sanitize-address">;
 
 // Issues with serialized diagnostics.
 def SerializedDiagnostics : DiagGroup<"serialized-diagnostics">;
 
 // A warning group for warnings about code that clang accepts when

clang/include/clang/Driver/Options.td

defm diagnostics_show_hotness : BoolFOption<"diagnostics-show-hotness",
   NegFlag<SetFalse>>;
 def fdiagnostics_hotness_threshold_EQ : Joined<["-"], "fdiagnostics-hotness-threshold=">,
     Group<f_Group>, Flags<[CC1Option]>, MetaVarName<"<value>">,
     HelpText<"Prevent optimization remarks from being output if they do not have at least this profile count. "
     "Use 'auto' to apply the threshold from profile summary">;
 def fdiagnostics_misexpect_tolerance_EQ : Joined<["-"], "fdiagnostics-misexpect-tolerance=">,
     Group<f_Group>, Flags<[CC1Option]>, MetaVarName<"<value>">,
     HelpText<"Prevent misexpect diagnostics from being output if the profile counts are within N% of the expected. ">;
+def fdiagnostics_misnoinline_percentile_EQ : Joined<["-"], "fdiagnostics-misnoinline-percentile-threshold=">,
+    Group<f_Group>, Flags<[CC1Option]>, MetaVarName<"<value>">,
+    HelpText<"Prevent misnoinline diagnostics from being output if the function is colder than N% of total entry counts. ">;
 defm diagnostics_show_option : BoolFOption<"diagnostics-show-option",
     DiagnosticOpts<"ShowOptionNames">, DefaultTrue,
     NegFlag<SetFalse, [CC1Option]>, PosFlag<SetTrue, [], "Print option name with mappable diagnostics">>;
 defm diagnostics_show_note_include_stack : BoolFOption<"diagnostics-show-note-include-stack",
     DiagnosticOpts<"ShowNoteIncludeStack">, DefaultFalse,
     PosFlag<SetTrue, [], "Display include stacks for diagnostic notes">,
     NegFlag<SetFalse>, BothFlags<[CC1Option]>>;
 def fdiagnostics_format_EQ : Joined<["-"], "fdiagnostics-format=">, Group<f_clang_Group>;

clang/lib/CodeGen/BackendUtil.cpp

if (!Entry.IsFramework &&
         (Entry.Group == frontend::IncludeDirGroup::Quoted ||
          Entry.Group == frontend::IncludeDirGroup::Angled ||
          Entry.Group == frontend::IncludeDirGroup::System))
       Options.MCOptions.IASSearchPaths.push_back(
           Entry.IgnoreSysRoot ? Entry.Path : HSOpts.Sysroot + Entry.Path);
   Options.MCOptions.Argv0 = CodeGenOpts.Argv0;
   Options.MCOptions.CommandLineArgs = CodeGenOpts.CommandLineArgs;
   Options.MisExpect = CodeGenOpts.MisExpect;
-
+  Options.MisNoInline = CodeGenOpts.MisNoInline;
   return true;
 }
 
 static Optional<GCOVOptions> getGCOVOptions(const CodeGenOptions &CodeGenOpts,
                                             const LangOptions &LangOpts) {
   if (!CodeGenOpts.EmitGcovArcs && !CodeGenOpts.EmitGcovNotes)
     return None;
   // Not using 'GCOVOptions::getDefault' allows us to avoid exiting if

clang/lib/CodeGen/CodeGenAction.cpp

void HandleTranslationUnit(ASTContext &C) override {
         Ctx.setMisExpectWarningRequested(true);
       }
 
       if (CodeGenOpts.DiagnosticsMisExpectTolerance) {
         Ctx.setDiagnosticsMisExpectTolerance(
             CodeGenOpts.DiagnosticsMisExpectTolerance);
       }
 
+      if (CodeGenOpts.MisNoInline)
+        Ctx.setMisNoInlineWarningRequested(true);
+
+      if (CodeGenOpts.DiagnosticsNoInlinePercentileThreshold)
+        Ctx.setDiagnosticsMisNoInlinePercentileThreshold(
+            CodeGenOpts.DiagnosticsNoInlinePercentileThreshold);
+
       // Link each LinkModule into our module.
       if (LinkInModules())
         return;
 
       for (auto &F : getModule()->functions()) {
         if (const Decl *FD = Gen->GetDeclForMangledName(F.getName())) {
           auto Loc = FD->getASTContext().getFullLoc(FD->getLocation());
           // TODO: use a fast content hash when available.
public:
     OptimizationRemarkHandler(const llvm::DiagnosticInfoOptimizationBase &D);
     void OptimizationRemarkHandler(
         const llvm::OptimizationRemarkAnalysisFPCommute &D);
     void OptimizationRemarkHandler(
         const llvm::OptimizationRemarkAnalysisAliasing &D);
     void OptimizationFailureHandler(
         const llvm::DiagnosticInfoOptimizationFailure &D);
     void DontCallDiagHandler(const DiagnosticInfoDontCall &D);
-    /// Specialized handler for misexpect warnings.
-    /// Note that misexpect remarks are emitted through ORE
+    /// Specialized handler for misexpect and misnoinline warnings.
+    /// Note that misexpect/misnoinline remarks are emitted through ORE
     void MisExpectDiagHandler(const llvm::DiagnosticInfoMisExpect &D);
+    void MisNoInlineDiagHandler(const llvm::DiagnosticInfoMisNoInline &D);
   };
 
   void BackendConsumer::anchor() {}
 }
 
 bool ClangDiagnosticHandler::handleDiagnostics(const DiagnosticInfo &DI) {
   BackendCon->DiagnosticHandlerImpl(DI);
   return true;
if (BadDebugInfo)
     // If we were not able to translate the file:line:col information
     // back to a SourceLocation, at least emit a note stating that
     // we could not translate this location. This can happen in the
     // case of #line directives.
     Diags.Report(Loc, diag::note_fe_backend_invalid_loc)
         << Filename << Line << Column;
 }
 
+void BackendConsumer::MisNoInlineDiagHandler(
+    const llvm::DiagnosticInfoMisNoInline &D) {
+  StringRef Filename;
+  unsigned Line, Column;
+  bool BadDebugInfo = false;
+  FullSourceLoc Loc =
+      getBestLocationFromDebugLoc(D, BadDebugInfo, Filename, Line, Column);
+  Diags.Report(Loc, diag::warn_profile_data_misnoinline)
+      << D.getFunction().getParent()->getName()
+      << llvm::demangle(D.getFunction().getName().str());
+  if (BadDebugInfo)
+    // If we were not able to translate the file:line:col information
+    // back to a SourceLocation, at least emit a note stating that
+    // we could not translate this location. This can happen in the
+    // case of #line directives.
+    Diags.Report(Loc, diag::note_fe_backend_invalid_loc)
+        << Filename << Line << Column;
+}
+
 /// This function is invoked when the backend needs
 /// to report something to the user.
 void BackendConsumer::DiagnosticHandlerImpl(const DiagnosticInfo &DI) {
   unsigned DiagID = diag::err_fe_inline_asm;
   llvm::DiagnosticSeverity Severity = DI.getSeverity();
   // Get the diagnostic ID based.
   switch (DI.getKind()) {
   case llvm::DK_InlineAsm:
case llvm::DK_Unsupported:
     UnsupportedDiagHandler(cast<DiagnosticInfoUnsupported>(DI));
     return;
   case llvm::DK_DontCall:
     DontCallDiagHandler(cast<DiagnosticInfoDontCall>(DI));
     return;
   case llvm::DK_MisExpect:
     MisExpectDiagHandler(cast<DiagnosticInfoMisExpect>(DI));
     return;
+  case llvm::DK_MisNoInline:
+    MisNoInlineDiagHandler(cast<DiagnosticInfoMisNoInline>(DI));
+    return;
   default:
     // Plugin IDs are not bound to any value as they are set dynamically.
     ComputeDiagRemarkID(Severity, backend_plugin, DiagID);
     break;
   }
   std::string MsgStorage;
   {
     raw_string_ostream Stream(MsgStorage);

clang/lib/Frontend/CompilerInvocation.cpp

 // Valid option values are integers in the range [0, 100)
 inline Expected<Optional<uint32_t>> parseToleranceOption(StringRef Arg) {
   uint32_t Val;
   if (Arg.getAsInteger(10, Val))
     return llvm::createStringError(llvm::inconvertibleErrorCode(),
                                    "Not an integer: %s", Arg.data());
   return Val;
 }
+// Parse misnoinline count value.
+// Valid option values are integers in the range [0, infinity)
+inline Optional<uint64_t> parseCountOption(StringRef Arg) {
+  int64_t Val;
+  if (Arg.getAsInteger(10, Val))
+    return Optional<uint64_t>();
+  return Val;
+}
 
 //===----------------------------------------------------------------------===//
 // Initialization.
 //===----------------------------------------------------------------------===//
 
 CompilerInvocationRefBase::CompilerInvocationRefBase()
     : LangOpts(new LangOptions()), TargetOpts(new TargetOptions()),
       DiagnosticOpts(new DiagnosticOptions()),
GenerateArg(Args, OPT_fdiagnostics_hotness_threshold_EQ,
               Opts.DiagnosticsHotnessThreshold
                   ? Twine(*Opts.DiagnosticsHotnessThreshold)
                   : "auto",
               SA);
 
   GenerateArg(Args, OPT_fdiagnostics_misexpect_tolerance_EQ,
               Twine(*Opts.DiagnosticsMisExpectTolerance), SA);
 
+  GenerateArg(Args, OPT_fdiagnostics_misnoinline_percentile_EQ,
+              Twine(*Opts.DiagnosticsNoInlinePercentileThreshold), SA);
+
   for (StringRef Sanitizer : serializeSanitizerKinds(Opts.SanitizeRecover))
     GenerateArg(Args, OPT_fsanitize_recover_EQ, Sanitizer, SA);
 
   for (StringRef Sanitizer : serializeSanitizerKinds(Opts.SanitizeTrap))
     GenerateArg(Args, OPT_fsanitize_trap_EQ, Sanitizer, SA);
 
   if (!Opts.EmitVersionIdentMetadata)
     GenerateArg(Args, OPT_Qn, SA);
if (!ResultOrErr) {
       if ((!Opts.DiagnosticsMisExpectTolerance ||
            Opts.DiagnosticsMisExpectTolerance.value() > 0) &&
           !UsingProfile)
         Diags.Report(diag::warn_drv_diagnostics_misexpect_requires_pgo)
             << "-fdiagnostics-misexpect-tolerance=";
     }
   }
 
+  if (auto *arg = Args.getLastArg(
+          options::OPT_fdiagnostics_misnoinline_percentile_EQ)) {
+    auto ResultOrErr = parseCountOption(arg->getValue());
+
+    if (!ResultOrErr) {
+      Diags.Report(diag::err_drv_invalid_diagnotics_misnoinline_threshold)
+          << "-fdiagnostics-misnoinline-percentile-threshold=";
+    } else {
+      Opts.DiagnosticsNoInlinePercentileThreshold = *ResultOrErr;
+      if ((!Opts.DiagnosticsNoInlinePercentileThreshold ||
+           Opts.MisNoInline == 1) &&
+          !UsingProfile) {
+        Diags.Report(diag::warn_drv_diagnostics_misexpect_requires_pgo)
+            << "-fdiagnostics-misnoinline-percentile-threshold=";
+      }
+    }
+  }
+
   // If the user requested to use a sample profile for PGO, then the
   // backend will need to track source location information so the profile
   // can be incorporated into the IR.
   if (UsingSampleProfile)
     NeedLocTracking = true;
 
   if (!Opts.StackUsageOutput.empty())
     NeedLocTracking = true;
bool CompilerInvocation::CreateFromArgsImpl(
   if (Res.getFrontendOpts().ProgramAction == frontend::RewriteObjC)
     LangOpts.ObjCExceptions = 1;
 
   for (auto Warning : Res.getDiagnosticOpts().Warnings) {
     if (Warning == "misexpect" &&
         !Diags.isIgnored(diag::warn_profile_data_misexpect, SourceLocation())) {
       Res.getCodeGenOpts().MisExpect = true;
     }
+    if (Warning == "misnoinline" &&
+        !Diags.isIgnored(diag::warn_profile_data_misnoinline,
+                         SourceLocation())) {
+      Res.getCodeGenOpts().MisNoInline = true;
+    }
   }
 
   if (LangOpts.CUDA) {
     // During CUDA device-side compilation, the aux triple is the
     // triple used for host compilation.
     if (LangOpts.CUDAIsDevice)
       Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
   }

clang/test/Misc/Inputs/MisNoInline.proftext

+_Z4foo1ii:2000:2000
+ 0: 2000
+ 1.1: 2000
+ 1.2: 2000
+ 2: 2000
+ 3: 2000
+ 5: 2000
+_Z4foo2ii:200:200
+ 0: 200
+ 1.1: 200
+ 1.2: 200
+ 2: 200
+ 3: 200
+ 5: 200
+main:1:1
+ 0: 1
+ 1: 1
+ 2: 1
+ 3: 1
+ 4: 1
+ 6: 1

clang/test/Misc/MisNoInline.cpp

+//Test that misnoinline emits correct warning
+
+// Test that without passing -fdiagnostics-misnoinline-count-threshold flag warning are emitted with percentile cuttof at 99%
+// This would mean both foo1 and foo2 would emit warning
+//  RUN: %clang_cc1 %s -O2 -o - -emit-llvm -fprofile-sample-use=%S/Inputs/MisNoInline.proftext -verify=emit -Wmisnoinline
+
+void printf();
+__attribute__((noinline)) long foo1(int x, int y) {
+  while (x != y) {
+    printf();
+    y++;
+  }
+  return y;
+}
+__attribute__((noinline)) long foo2(int x, int y) {
+  while (x != y) {
+    printf();
+    y++;
+  }
+  return y;
+}
+int main() {
+  int x = 5678;
+  int y = 1234;
+  x += foo1(x, y); // emit-warning-re {{noinline attribute marking for {{.*}}MisNoInline.cpp:foo1(int, int) may hurt performance.}}
+  x += foo2(x, y); // emit-warning-re {{noinline attribute marking for {{.*}}MisNoInline.cpp:foo2(int, int) may hurt performance.}}
+
+  return x;
+}

clang/test/Misc/MisNoInline_LowThreshold.cpp

+//Test that misnoinline emits correct warning
+
+// Test that with -fdiagnostics-misnoinline-percentile-threshold set to 90% only foo1 emits warning as per profiling data
+//  RUN: %clang_cc1 %s -O2 -o - -emit-llvm -fprofile-sample-use=%S/Inputs/MisNoInline.proftext  -verify=emit -Wmisnoinline -fdiagnostics-misnoinline-percentile-threshold=900000
+
+void printf();
+__attribute__((noinline)) long foo1(int x, int y) {
+  while (x != y) {
+    printf();
+    y++;
+  }
+  return y;
+}
+__attribute__((noinline)) long foo2(int x, int y) {
+  while (x != y) {
+    printf();
+    y++;
+  }
+  return y;
+}
+int main() {
+  int x = 5678;
+  int y = 1234;
+  x += foo1(x, y); // emit-warning-re {{noinline attribute marking for {{.*}}MisNoInline_LowThreshold.cpp:foo1(int, int) may hurt performance.}}
+  x += foo2(x, y);
+
+  return x;
+}

clang/test/Misc/MisNoInline_PragmaIgnore.cpp

+// Test that misnoinline dosent emit warning when it is pragma ignored
+
+//  RUN: %clang_cc1 %s -O2 -o - -emit-llvm -fprofile-sample-use=%S/Inputs/MisNoInline.proftext -verify=noemit -Wmisnoinline
+
+//  RUN: %clang_cc1 %s -O2 -o - -emit-llvm -fprofile-sample-use=%S/Inputs/MisNoInline.proftext -verify=noemit -Wmisnoinline -fdiagnostics-misnoinline-percentile-threshold=900000
+
+//noemit-no-diagnostics
+void printf();
+__attribute__((noinline)) long foo1(int x, int y) {
+  while (x != y) {
+    printf();
+    y++;
+  }
+  return y;
+}
+__attribute__((noinline)) long foo2(int x, int y) {
+  while (x != y) {
+    printf();
+    y++;
+  }
+  return y;
+}
+
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wmisnoinline"
+int main() {
+  int x = 5678;
+  int y = 1234;
+  x += foo1(x, y);
+  x += foo2(x, y);
+
+  return x;
+}
+#pragma clang diagnostic pop

llvm/docs/MisNoInline.rst

+===================
+Misnoexpect
+===================
+.. contents::
+
+.. toctree::
+   :maxdepth: 1
+
+When developers use noinline attribute with a function, i.e., through use of
+``__attribute__((noinline))``, they are trying to communicate that the
+function should not be inlined by the compiler. These can be due to various
+number of reasons to mark a function noinline. If a function is small,
+not critical to the performance of your code and would be called less often,
+especially in cases of error handling, it makes sense to noinline a function.
+These annotations, however, can be incorrect for a variety of reasons:
+changes to the code base may make these functions hot, the developer
+mis-annotated them, or perhaps they assumed something incorrectly when they
+wrote the annotation. Regardless of why, it is useful to detect these
+situations so that the user can rethink and remove the attribute as necessary.
+
+The MisNoInline checks in the LLVM backend follow a simple procedure: if the function entry
+entry count exceeds a certain percentile threshold and the cost of inlining the noinline marked
+function indicates a success, the MisNoInline flags will emit a diagnostic to the user to reconsider
+their stance on the function marking.
+
+The most natural place to perform these checks is in the CGSCC Inliner pass specifically
+where we check the cost of inlining the function. The profile pass has also been run
+up to this point, so information about BFI/PSI is available for further analysis.
+
+
+Instead of stopping our analysis on whether a function needs to be inlined
+in InlinerCost, if we hit a noinline marked function we continue and see if by cost it is
+feasible to inline a function. If so, we do one more check if the function is percentile wise
+hotter than user provided value (If user doesn't provide the value it's 99% by default), and go
+ahead and emit the warning.
+
+The diagnostics are also available in the form of optimization remarks,
+which can be serialized and processed through the ``opt-viewer.py``
+scripts in LLVM.
+
+.. option:: -pass-remarks=misnoinline
+
+  Enables optimization remarks for misnoinline when profiling data conflicts with
+  use of ``noinline`` function attribute.
+
+
+.. option:: pgo-warn-misnoinline
+
+  Enables misnoinline warnings when profiling data conflicts with use of
+  ``noinline`` function attribute.
+
+.. option:: misnoinline-percent
+
+  Relaxes misnoinline checking to not emit warnings for functions colder than Nth percentile.
+
+LLVM supports 4 types of profile formats: Frontend, IR, CS-IR, and
+Sampling. MisNoInline Diagnostics are compatible with all profiling formats.
+
++----------------+--------------------------------------------------------------------------------------+
+| Profile Type   | Description                                                                          |
++================+======================================================================================+
+| Frontend       | Profiling instrumentation added during compilation by the frontend, i.e. ``clang``   |
++----------------+--------------------------------------------------------------------------------------+
+| IR             | Profiling instrumentation added during by the LLVM backend                           |
++----------------+--------------------------------------------------------------------------------------+
+| CS-IR          | Context Sensitive IR based profiles                                                  |
++----------------+--------------------------------------------------------------------------------------+
+| Sampling       | Profiles collected through sampling with external tools, such as ``perf`` on Linux   |
++----------------+--------------------------------------------------------------------------------------+

llvm/include/llvm/Analysis/InlineCost.h

class InlineCost {
   int Threshold = 0;
 
   /// Must be set for Always and Never instances.
   const char *Reason = nullptr;
 
   /// The cost-benefit pair computed by cost-benefit analysis.
   Optional<CostBenefitPair> CostBenefit = None;
 
+  bool IsNoInline = false;
+
   // Trivial constructor, interesting logic in the factory functions below.
   InlineCost(int Cost, int Threshold, const char *Reason = nullptr,
              Optional<CostBenefitPair> CostBenefit = None)
       : Cost(Cost), Threshold(Threshold), Reason(Reason),
         CostBenefit(CostBenefit) {
     assert((isVariable() || Reason) &&
            "Reason must be provided for Never or Always");
   }
assert((Reason || isVariable()) &&
            "InlineCost reason must be set for Always or Never");
     return Reason;
   }
 
   /// Get the cost delta from the threshold for inlining.
   /// Only valid if the cost is of the variable kind. Returns a negative
   /// value if the cost is too high to inline.
   int getCostDelta() const { return Threshold - getCost(); }
+
+  // Set cost is due to function being marked noinline
+  void setIsNoInline() { IsNoInline = true; }
+  bool isNoInline() const { return IsNoInline; }
 };
 
 /// InlineResult is basically true or false. For false results the message
 /// describes a reason.
 class InlineResult {
   const char *Message = nullptr;
+  bool IsNoInline = false;
   InlineResult(const char *Message = nullptr) : Message(Message) {}
 
 public:
   static InlineResult success() { return {}; }
   static InlineResult failure(const char *Reason) {
     return InlineResult(Reason);
   }
   bool isSuccess() const { return Message == nullptr; }
   const char *getFailureReason() const {
     assert(!isSuccess() &&
            "getFailureReason should only be called in failure cases");
     return Message;
   }
+  bool isNoInline() const { return IsNoInline; }
+  void setIsNoInline() { IsNoInline = true; }
 };
 
 /// Thresholds to tune inline cost analysis. The inline cost analysis decides
 /// the condition to apply a threshold and applies it. Otherwise,
 /// DefaultThreshold is used. If a threshold is Optional, it is applied only
 /// when it has a valid value. Typically, users of inline cost analysis
 /// obtain an InlineParams object through one of the \c getInlineParams methods
 /// and pass it to \c getInlineCost. Some specialized versions of inliner

 /// InlineResult::failure() if the inlining may never happen because of user
 /// directives or incompatibilities detectable without needing callee traversal.
 /// Otherwise returns None, meaning that inlining should be decided based on
 /// other criteria (e.g. cost modeling).
 Optional<InlineResult> getAttributeBasedInliningDecision(
     CallBase &Call, Function *Callee, TargetTransformInfo &CalleeTTI,
     function_ref<const TargetLibraryInfo &(Function &)> GetTLI);
 
+// Check if a no inline function would have been inlined based on cost decision
+InlineCost isInlineViableFromCostAnalysis(
+    CallBase &Call, Function *Callee, const InlineParams &Params,
+    TargetTransformInfo &CalleeTTI,
+    function_ref<AssumptionCache &(Function &)> GetAssumptionCache,
+    function_ref<const TargetLibraryInfo &(Function &)> GetTLI,
+    function_ref<BlockFrequencyInfo &(Function &)> GetBFI = nullptr,
+    ProfileSummaryInfo *PSI = nullptr,
+    OptimizationRemarkEmitter *ORE = nullptr);
+
 /// Get the cost estimate ignoring thresholds. This is similar to getInlineCost
 /// when passed InlineParams::ComputeFullInlineCost, or a non-null ORE. It
 /// uses default InlineParams otherwise.
 /// Contrary to getInlineCost, which makes a threshold-based final evaluation of
 /// should/shouldn't inline, captured in InlineResult, getInliningCostEstimate
 /// returns:
 /// - None, if the inlining cannot happen (is illegal)
 /// - an integer, representing the cost.

llvm/include/llvm/IR/DiagnosticInfo.h

enum DiagnosticKind {
   DK_FirstMachineRemark = DK_MachineOptimizationRemark,
   DK_LastMachineRemark = DK_MachineOptimizationRemarkAnalysis,
   DK_MIRParser,
   DK_PGOProfile,
   DK_Unsupported,
   DK_SrcMgr,
   DK_DontCall,
   DK_MisExpect,
+  DK_MisNoInline,
   DK_FirstPluginKind // Must be last value to work with
                      // getNextAvailablePluginDiagnosticKind
 };
 
 /// Get the next available kind ID for a plugin diagnostic.
 /// Each time this function is called, it returns a different number.
 /// Therefore, a plugin that wants to "identify" its own classes
 /// with a dynamic identifier, just have to use this method to get a new ID
public:
 
   /// Return location information for this diagnostic in three parts:
   /// the relative source file path, line number and column.
   void getLocation(StringRef &RelativePath, unsigned &Line,
                    unsigned &Column) const;
 
   /// Return the absolute path tot the file.
   std::string getAbsolutePath() const;
-  
   const Function &getFunction() const { return Fn; }
   DiagnosticLocation getLocation() const { return Loc; }
 
 private:
   /// Function where this diagnostic is triggered.
   const Function &Fn;
 
   /// Debug location where this diagnostic is triggered.
public:
 
   const Twine &getMsg() const { return Msg; }
 
 private:
   /// Message to report.
   const Twine &Msg;
 };
 
+/// Diagnostic information for MisNoInline analysis.
+/// Diagnostic information for ISel fallback path.
+class DiagnosticInfoMisNoInline : public DiagnosticInfoWithLocationBase {
+  /// The function that is concerned by this diagnostic.
+  /// const Twine &Msg;
+private:
+  const Function &Fn;
+  const Twine &Msg;
+
+public:
+  DiagnosticInfoMisNoInline(const Instruction *Inst, const Function &Fn,
+                            Twine &Msg);
+  const Function &getFunction() const { return Fn; }
+
+  void print(DiagnosticPrinter &DP) const override;
+
+  static bool classof(const DiagnosticInfo *DI) {
+    return DI->getKind() == DK_MisNoInline;
+  }
+  const Twine &getMsg() const { return Msg; }
+};
+
 static DiagnosticSeverity getDiagnosticSeverity(SourceMgr::DiagKind DK) {
   switch (DK) {
   case llvm::SourceMgr::DK_Error:
     return DS_Error;
     break;
   case llvm::SourceMgr::DK_Warning:
     return DS_Warning;
     break;

llvm/include/llvm/IR/LLVMContext.h

#undef LLVM_FIXED_MD_KIND
   /// diagnostics.
   void setDiagnosticsHotnessRequested(bool Requested);
 
   bool getMisExpectWarningRequested() const;
   void setMisExpectWarningRequested(bool Requested);
   void setDiagnosticsMisExpectTolerance(Optional<uint32_t> Tolerance);
   uint32_t getDiagnosticsMisExpectTolerance() const;
 
+  /// Return if a code noinline diagnostic needs to be emitted
+  bool getMisNoInlineWarningRequested() const;
+  /// Set noinline diagnostic
+  void setMisNoInlineWarningRequested(bool Requested);
+  // Get/set for NoInline count threshold
+  void
+  setDiagnosticsMisNoInlinePercentileThreshold(Optional<uint64_t> Threshold);
+  uint64_t getDiagnosticsMisNoInlinePercentileThreshold() const;
   /// Return the minimum hotness value a diagnostic would need in order
   /// to be included in optimization diagnostics.
   ///
   /// Three possible return values:
   /// 0            - threshold is disabled. Everything will be printed out.
   /// positive int - threshold is set.
   /// UINT64_MAX   - threshold is not yet set, and needs to be synced from
   ///                profile summary. Note that in case of missing profile

llvm/include/llvm/Target/TargetOptions.h

TargetOptions()
           ExplicitEmulatedTLS(false), EnableIPRA(false),
           EmitStackSizeSection(false), EnableMachineOutliner(false),
           EnableMachineFunctionSplitter(false), SupportsDefaultOutlining(false),
           EmitAddrsig(false), EmitCallSiteInfo(false),
           SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
           ValueTrackingVariableLocations(false), ForceDwarfFrameSection(false),
           XRayOmitFunctionIndex(false), DebugStrictDwarf(false),
           Hotpatch(false), PPCGenScalarMASSEntries(false), JMCInstrument(false),
-          EnableCFIFixup(false), MisExpect(false),
+          EnableCFIFixup(false), MisExpect(false), MisNoInline(false),
           FPDenormalMode(DenormalMode::IEEE, DenormalMode::IEEE) {}
 
     /// DisableFramePointerElim - This returns true if frame pointer elimination
     /// optimization should be disabled for the given machine function.
     bool DisableFramePointerElim(const MachineFunction &MF) const;
 
     /// If greater than 0, override the default value of
     /// MCAsmInfo::BinutilsVersion.
public:
 
     /// Enable the CFIFixup pass.
     unsigned EnableCFIFixup : 1;
 
     /// When set to true, enable MisExpect Diagnostics
     /// By default, it is set to false
     unsigned MisExpect : 1;
 
+    /// When set to true, enable MisNoInline Diagnostics
+    /// By default, it is set to false
+    unsigned MisNoInline : 1;
+
     /// Name of the stack usage file (i.e., .su file) if user passes
     /// -fstack-usage. If empty, it can be implied that -fstack-usage is not
     /// passed on the command line.
     std::string StackUsageOutput;
 
     /// If greater than 0, override TargetLoweringBase::PrefLoopAlignment.
     unsigned LoopAlignment = 0;
 

llvm/lib/Analysis/InlineAdvisor.cpp

 #include "llvm/Analysis/Utils/ImportedFunctionsInliningStatistics.h"
 #include "llvm/IR/DebugInfoMetadata.h"
 #include "llvm/IR/PassManager.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/raw_ostream.h"
 
 using namespace llvm;
 #define DEBUG_TYPE "inline"
+#define DEBUG_TYPE_WARN "misnoinline"
 #ifdef LLVM_HAVE_TF_AOT_INLINERSIZEMODEL
 #define LLVM_HAVE_TF_AOT
 #endif
 
 // This weirdly named statistic tracks the number of times that, when attempting
 // to inline a function A into B, we analyze the callers of B in order to see
 // if those would be more profitable and blocked inline steps.
 STATISTIC(NumCallerCallersAnalyzed, "Number of caller-callers analyzed");
InlineDeferralScale("inline-deferral-scale",
                         cl::desc("Scale to limit the cost of inline deferral"),
                         cl::init(2), cl::Hidden);
 
 static cl::opt<bool>
     AnnotateInlinePhase("annotate-inline-phase", cl::Hidden, cl::init(false),
                         cl::desc("If true, annotate inline advisor remarks "
                                  "with LTO and pass information."));
 
+// Command line option to enable/disable the warning when profile data suggests
+// a mismatch with the use of the noinline attribute
+static cl::opt<bool> PGOWarnMisNoInline(
+    "pgo-warn-misnoinline", cl::init(false), cl::Hidden,
+    cl::desc("Use this option to turn on/off "
+             "warnings about usage of noinline function attribute "
+             "which may hurt performance."));
+
+// Command line opt option to noinline count threshold
+static cl::opt<unsigned> MisNoInlinePercent(
+    "misnoinline-percent",
+    cl::desc("Prevents emiting diagnostics when function is colder"
+             "that N percentile of total entry counts."));
+
 extern cl::opt<InlinerFunctionImportStatsOpts> InlinerFunctionImportStats;
 
 namespace {
 using namespace llvm::ore;
 class MandatoryInlineAdvice : public InlineAdvice {
 public:
   MandatoryInlineAdvice(InlineAdvisor *Advisor, CallBase &CB,
                         OptimizationRemarkEmitter &ORE,

 
 void DefaultInlineAdvice::recordInliningImpl() {
   if (EmitRemarks)
     emitInlinedIntoBasedOnCost(ORE, DLoc, Block, *Callee, *Caller, *OIC,
                                /* ForProfileContext= */ false,
                                Advisor->getAnnotatedInlinePassName());
 }
 
+static bool canEmitNoInlineWarning(CallBase *CB, InlineCost &IC,
+                                   FunctionAnalysisManager &FAM) {
+  Function &Callee = *CB->getCalledFunction();
+  LLVMContext &Ctx = Callee.getContext();
+  const char *reason = IC.getReason();
+
+  // Check if pass remarks, Wmisnoinline or pgo-warn-misnoinline said anything
+  // about warning
+  if (!OptimizationRemark(DEBUG_TYPE_WARN, "misnoinline", CB).isEnabled() &&
+      !PGOWarnMisNoInline && !Ctx.getMisNoInlineWarningRequested())
+    return false;
+  // If Callee has no profile data bail out
+  if (!Callee.hasProfileData())
+    return false;
+  // Failiure reason is due to noinline callee/call site attribute
+  if (reason == nullptr)
+    return false;
+  if (!IC.isNoInline())
+    return false;
+  uint64_t Percent_Threshold;
+  if (MisNoInlinePercent)
+    Percent_Threshold = MisNoInlinePercent;
+  else
+    Percent_Threshold = Ctx.getDiagnosticsMisNoInlinePercentileThreshold();
+  ProfileSummaryInfo *PSI =
+      FAM.getResult<ModuleAnalysisManagerFunctionProxy>(Callee)
+          .getCachedResult<ProfileSummaryAnalysis>(*Callee.getParent());
+  if (!PSI)
+    return false;
+  BlockFrequencyInfo &CalleeBFI = FAM.getResult<BlockFrequencyAnalysis>(Callee);
+  if (!PSI->isFunctionHotInCallGraphNthPercentile(Percent_Threshold, &Callee,
+                                                  CalleeBFI))
+    return false;
+  // we have checked all conditions we are safe to
+  // check for cost and emit warning
+  return true;
+}
+
+// Emit a noinline diagnostic if:
+// 1. Function entry is hotter than the supplied thrshold in terms of total
+// entry count
+// 2. The noinline function could have been inlined by cost metric. This part is
+// checked when normal inlining fails due to noinline attribute
+static void emitNoInlineWarning(Function *Callee, Function *Caller,
+                                CallBase *CB) {
+  llvm::LLVMContext &Ctx = Caller->getContext();
+  auto RemStr =
+      formatv("Marking {0} noinline while calling in {1} "
+              "may hurt performance as per inline cost/hotness analysis",
+              Callee->getName(), Caller->getName());
+  Twine Msg(RemStr);
+  if (PGOWarnMisNoInline || Ctx.getMisNoInlineWarningRequested())
+    Ctx.diagnose(DiagnosticInfoMisNoInline(CB, *Callee, Msg));
+  OptimizationRemarkEmitter ORE(CB->getParent()->getParent());
+  ORE.emit(OptimizationRemark(DEBUG_TYPE_WARN, "misnoinline", CB)
+           << RemStr.str());
+}
+
 llvm::Optional<llvm::InlineCost> static getDefaultInlineAdvice(
     CallBase &CB, FunctionAnalysisManager &FAM, const InlineParams &Params) {
   Function &Caller = *CB.getCaller();
   ProfileSummaryInfo *PSI =
       FAM.getResult<ModuleAnalysisManagerFunctionProxy>(Caller)
           .getCachedResult<ProfileSummaryAnalysis>(
               *CB.getParent()->getParent()->getParent());
 
llvm::Optional<llvm::InlineCost> static getDefaultInlineAdvice(
   };
 
   auto GetInlineCost = [&](CallBase &CB) {
     Function &Callee = *CB.getCalledFunction();
     auto &CalleeTTI = FAM.getResult<TargetIRAnalysis>(Callee);
     bool RemarksEnabled =
         Callee.getContext().getDiagHandlerPtr()->isMissedOptRemarkEnabled(
             DEBUG_TYPE);
-    return getInlineCost(CB, Params, CalleeTTI, GetAssumptionCache, GetTLI,
-                         GetBFI, PSI, RemarksEnabled ? &ORE : nullptr);
+    InlineCost IC =
+        getInlineCost(CB, Params, CalleeTTI, GetAssumptionCache, GetTLI, GetBFI,
+                      PSI, RemarksEnabled ? &ORE : nullptr);
+    // Check if we should emit a warning for noinline function
+    if (LLVM_UNLIKELY(canEmitNoInlineWarning(&CB, IC, FAM))) {
+      Function &Callee = *CB.getCalledFunction();
+      auto &CalleeTTI = FAM.getResult<TargetIRAnalysis>(Callee);
+      auto TempIC = llvm::isInlineViableFromCostAnalysis(
+          CB, &Callee, Params, CalleeTTI, GetAssumptionCache, GetTLI, GetBFI,
+          PSI);
+
+      if (TempIC.isAlways() || TempIC)
+        emitNoInlineWarning(&Callee, &Caller, &CB);
+    }
+    return IC;
   };
+
   return llvm::shouldInline(
       CB, GetInlineCost, ORE,
       Params.EnableDeferral.value_or(EnableInlineDeferral));
 }
 
 std::unique_ptr<InlineAdvice>
 DefaultInlineAdvisor::getAdviceImpl(CallBase &CB) {
   auto OIC = getDefaultInlineAdvice(CB, FAM, Params);

llvm/lib/Analysis/InlineCost.cpp

Optional<InlineResult> llvm::getAttributeBasedInliningDecision(
   if (!Caller->nullPointerIsDefined() && Callee->nullPointerIsDefined())
     return InlineResult::failure("nullptr definitions incompatible");
 
   // Don't inline functions which can be interposed at link-time.
   if (Callee->isInterposable())
     return InlineResult::failure("interposable");
 
   // Don't inline functions marked noinline.
-  if (Callee->hasFnAttribute(Attribute::NoInline))
-    return InlineResult::failure("noinline function attribute");
+  if (Callee->hasFnAttribute(Attribute::NoInline)) {
+    auto IR = InlineResult::failure("noinline function attribute");
+    IR.setIsNoInline();
+    return IR;
+  }
 
   // Don't inline call sites marked noinline.
-  if (Call.isNoInline())
-    return InlineResult::failure("noinline call site attribute");
+  if (Call.isNoInline()) {
+    auto IR = InlineResult::failure("noinline call site attribute");
+    IR.setIsNoInline();
+    return IR;
+  }
 
   return None;
 }
 
-InlineCost llvm::getInlineCost(
+InlineCost llvm::isInlineViableFromCostAnalysis(
     CallBase &Call, Function *Callee, const InlineParams &Params,
     TargetTransformInfo &CalleeTTI,
     function_ref<AssumptionCache &(Function &)> GetAssumptionCache,
     function_ref<const TargetLibraryInfo &(Function &)> GetTLI,
     function_ref<BlockFrequencyInfo &(Function &)> GetBFI,
     ProfileSummaryInfo *PSI, OptimizationRemarkEmitter *ORE) {
-
-  auto UserDecision =
-      llvm::getAttributeBasedInliningDecision(Call, Callee, CalleeTTI, GetTLI);
-
-  if (UserDecision) {
-    if (UserDecision->isSuccess())
-      return llvm::InlineCost::getAlways("always inline attribute");
-    return llvm::InlineCost::getNever(UserDecision->getFailureReason());
-  }
-
   LLVM_DEBUG(llvm::dbgs() << "      Analyzing call of " << Callee->getName()
                           << "... (caller:" << Call.getCaller()->getName()
                           << ")\n");
 
   InlineCostCallAnalyzer CA(*Callee, Call, Params, CalleeTTI,
                             GetAssumptionCache, GetBFI, PSI, ORE);
   InlineResult ShouldInline = CA.analyze();
 
if (CA.wasDecidedByCostThreshold())
     return InlineCost::get(CA.getCost(), CA.getThreshold());
 
   // No details on how the decision was made, simply return always or never.
   return ShouldInline.isSuccess()
              ? InlineCost::getAlways("empty function")
              : InlineCost::getNever(ShouldInline.getFailureReason());
 }
 
+InlineCost llvm::getInlineCost(
+    CallBase &Call, Function *Callee, const InlineParams &Params,
+    TargetTransformInfo &CalleeTTI,
+    function_ref<AssumptionCache &(Function &)> GetAssumptionCache,
+    function_ref<const TargetLibraryInfo &(Function &)> GetTLI,
+    function_ref<BlockFrequencyInfo &(Function &)> GetBFI,
+    ProfileSummaryInfo *PSI, OptimizationRemarkEmitter *ORE) {
+
+  auto UserDecision =
+      llvm::getAttributeBasedInliningDecision(Call, Callee, CalleeTTI, GetTLI);
+  if (UserDecision) {
+    if (UserDecision->isSuccess())
+      return llvm::InlineCost::getAlways("always inline attribute");
+    auto IC = llvm::InlineCost::getNever(UserDecision->getFailureReason());
+    if (UserDecision->isNoInline())
+      IC.setIsNoInline();
+    return IC;
+  }
+  return llvm::isInlineViableFromCostAnalysis(Call, Callee, Params, CalleeTTI,
+                                              GetAssumptionCache, GetTLI,
+                                              GetBFI, PSI, ORE);
+}
+
 InlineResult llvm::isInlineViable(Function &F) {
   bool ReturnsTwice = F.hasFnAttribute(Attribute::ReturnsTwice);
   for (BasicBlock &BB : F) {
     // Disallow inlining of functions which contain indirect branches.
     if (isa<IndirectBrInst>(BB.getTerminator()))
       return InlineResult::failure("contains indirect branches");
 
     // Disallow inlining of blockaddresses which are used by non-callbr

llvm/lib/IR/DiagnosticInfo.cpp

: DiagnosticInfoWithLocationBase(DK_MisExpect, DS_Warning,
                                      *Inst->getParent()->getParent(),
                                      Inst->getDebugLoc()),
       Msg(Msg) {}
 
 void DiagnosticInfoMisExpect::print(DiagnosticPrinter &DP) const {
   DP << getLocationStr() << ": " << getMsg();
 }
 
+DiagnosticInfoMisNoInline::DiagnosticInfoMisNoInline(const Instruction *Inst,
+                                                     const Function &Fn,
+                                                     Twine &Msg)
+    : DiagnosticInfoWithLocationBase(DK_MisNoInline, DS_Warning,
+                                     *Inst->getParent()->getParent(),
+                                     Inst->getDebugLoc()),
+      Fn(Fn), Msg(Msg) {}
+
+void DiagnosticInfoMisNoInline::print(DiagnosticPrinter &DP) const {
+  DP << "Module"
+     << ": " << getFunction().getParent()->getName() << " " << getMsg();
+}
+
 void OptimizationRemarkAnalysisFPCommute::anchor() {}
 void OptimizationRemarkAnalysisAliasing::anchor() {}
 
 void llvm::diagnoseDontCall(const CallInst &CI) {
   auto *F = CI.getCalledFunction();
   if (!F)
     return;
 

llvm/lib/IR/LLVMContext.cpp

 void LLVMContext::setDiagnosticsMisExpectTolerance(
     Optional<uint32_t> Tolerance) {
   pImpl->DiagnosticsMisExpectTolerance = Tolerance;
 }
 uint32_t LLVMContext::getDiagnosticsMisExpectTolerance() const {
   return pImpl->DiagnosticsMisExpectTolerance.value_or(0);
 }
 
+void LLVMContext::setMisNoInlineWarningRequested(bool Requested) {
+  pImpl->MisNoInlineWarningRequested = Requested;
+}
+bool LLVMContext::getMisNoInlineWarningRequested() const {
+  return pImpl->MisNoInlineWarningRequested;
+}
+void LLVMContext::setDiagnosticsMisNoInlinePercentileThreshold(
+    Optional<uint64_t> Count) {
+  pImpl->DiagnosticsMisNoInlinePercentile = Count;
+}
+uint64_t LLVMContext::getDiagnosticsMisNoInlinePercentileThreshold() const {
+  return pImpl->DiagnosticsMisNoInlinePercentile.value_or(0);
+}
 bool LLVMContext::isDiagnosticsHotnessThresholdSetFromPSI() const {
   return !pImpl->DiagnosticsHotnessThreshold.has_value();
 }
 
 remarks::RemarkStreamer *LLVMContext::getMainRemarkStreamer() {
   return pImpl->MainRemarkStreamer.get();
 }
 const remarks::RemarkStreamer *LLVMContext::getMainRemarkStreamer() const {

llvm/lib/IR/LLVMContextImpl.h

public:
   /// If threshold option is not specified, it is disabled (0) by default.
   Optional<uint64_t> DiagnosticsHotnessThreshold = 0;
 
   /// The percentage of difference between profiling branch weights and
   /// llvm.expect branch weights to tolerate when emiting MisExpect diagnostics
   Optional<uint32_t> DiagnosticsMisExpectTolerance = 0;
   bool MisExpectWarningRequested = false;
 
+  /// The percentile of hotness of a function
+  //  when emiting MisNoInline diagnostics
+  Optional<uint64_t> DiagnosticsMisNoInlinePercentile = 990000;
+  bool MisNoInlineWarningRequested = false;
+
   /// The specialized remark streamer used by LLVM's OptimizationRemarkEmitter.
   std::unique_ptr<LLVMRemarkStreamer> LLVMRS;
 
   LLVMContext::YieldCallbackTy YieldCallback = nullptr;
   void *YieldOpaqueHandle = nullptr;
 
   DenseMap<const Value *, ValueName *> ValueNames;
 

llvm/test/Transforms/PGOProfile/Inputs/MisNoInline.proftext

+_Z4foo1ii:2000:2000
+ 0: 2000
+ 1.1: 2000
+ 1.2: 2000
+ 2: 2000
+ 3: 2000
+ 5: 2000
+_Z4foo2ii:200:200
+ 0: 200
+ 1.1: 200
+ 1.2: 200
+ 2: 200
+ 3: 200
+ 5: 200
+main:1:1
+ 0: 1
+ 1: 1
+ 2: 1
+ 3: 1
+ 4: 1
+ 6: 1

llvm/test/Transforms/PGOProfile/MisNoInline.ll

+; RUN: opt < %s -passes=sample-profile,inline -sample-profile-file=%S/Inputs/MisNoInline.proftext -pgo-warn-misnoinline -S  2>&1 | FileCheck %s -check-prefix=WARNING
+; RUN: opt < %s -passes=sample-profile,inline -sample-profile-file=%S/Inputs/MisNoInline.proftext -pgo-warn-misnoinline -misnoinline-percent=900000 -S  2>&1 | FileCheck %s -check-prefix=WARNING_LOW
+; RUN: opt < %s -passes=sample-profile,inline -sample-profile-file=%S/Inputs/MisNoInline.proftext -pass-remarks=misnoinline -S 2>&1 | FileCheck %s --check-prefix=REMARK
+
+; WARNING-DAG: warning: Module: {{.*}} Marking _Z4foo1ii noinline while calling in main may hurt performance as per inline cost/hotness analysis
+; WARNING-DAG: warning: Module: {{.*}} Marking _Z4foo2ii noinline while calling in main may hurt performance as per inline cost/hotness analysis
+
+; WARNING_LOW-DAG: warning: Module: {{.*}} Marking _Z4foo1ii noinline while calling in main may hurt performance as per inline cost/hotness analysis
+; WARNING_LOW-NOT: warning: Module: {{.*}} Marking _Z4foo2ii noinline while calling in main may hurt performance as per inline cost/hotness analysis
+
+; REMARK-NOT: warning: Module: {{.*}} Marking _Z4foo1ii noinline while calling in main may hurt performance as per inline cost/hotness analysis
+; REMARK-NOT: warning: Module: {{.*}} Marking _Z4foo2ii noinline while calling in main may hurt performance as per inline cost/hotness analysis
+; REMARK-DAG: remark: MisNoInline.cpp:28:8: Marking _Z4foo1ii noinline while calling in main may hurt performance as per inline cost/hotness analysis
+; REMARK-DAG: remark: MisNoInline.cpp:29:8: Marking _Z4foo2ii noinline while calling in main may hurt performance as per inline cost/hotness analysis
+
+; The source code used for the LLVM IR that follows.
+; void printf();
+; __attribute__((noinline)) long foo1(int x, int y) {
+;   while (x != y) {
+;     printf();
+;     y++;
+;   }
+;   return y;
+; }
+; __attribute__((noinline)) long foo2(int x, int y) {
+;   while (x != y) {
+;     printf();
+;     y++;
+;   }
+;   return y;
+; }
+; int main() {
+;   int x = 5678;
+;   int y = 1234;
+;   x += foo1(x, y);
+;   x += foo2(x, y);
+;
+;   return x;
+; }
+
+; Function Attrs: mustprogress noinline optnone uwtable
+define dso_local noundef i64 @_Z4foo1ii(i32 noundef %x, i32 noundef %y) #0 !dbg !8 {
+entry:
+  %x.addr = alloca i32, align 4
+  %y.addr = alloca i32, align 4
+  store i32 %x, ptr %x.addr, align 4
+  call void @llvm.dbg.declare(metadata ptr %x.addr, metadata !14, metadata !DIExpression()), !dbg !15
+  store i32 %y, ptr %y.addr, align 4
+  call void @llvm.dbg.declare(metadata ptr %y.addr, metadata !16, metadata !DIExpression()), !dbg !17
+  br label %while.cond, !dbg !18
+
+while.cond:                                       ; preds = %while.body, %entry
+  %0 = load i32, ptr %x.addr, align 4, !dbg !19
+  %1 = load i32, ptr %y.addr, align 4, !dbg !21
+  %cmp = icmp ne i32 %0, %1, !dbg !22
+  br i1 %cmp, label %while.body, label %while.end, !dbg !23
+
+while.body:                                       ; preds = %while.cond
+  call void @_Z6printfv(), !dbg !24
+  %2 = load i32, ptr %y.addr, align 4, !dbg !26
+  %inc = add nsw i32 %2, 1, !dbg !26
+  store i32 %inc, ptr %y.addr, align 4, !dbg !26
+  br label %while.cond, !dbg !27, !llvm.loop !29
+
+while.end:                                        ; preds = %while.cond
+  %3 = load i32, ptr %y.addr, align 4, !dbg !32
+  %conv = sext i32 %3 to i64, !dbg !32
+  ret i64 %conv, !dbg !33
+}
+
+; Function Attrs: nocallback nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
+
+declare dso_local void @_Z6printfv() #2
+
+; Function Attrs: mustprogress noinline optnone uwtable
+define dso_local noundef i64 @_Z4foo2ii(i32 noundef %x, i32 noundef %y) #0 !dbg !34 {
+entry:
+  %x.addr = alloca i32, align 4
+  %y.addr = alloca i32, align 4
+  store i32 %x, ptr %x.addr, align 4
+  call void @llvm.dbg.declare(metadata ptr %x.addr, metadata !35, metadata !DIExpression()), !dbg !36
+  store i32 %y, ptr %y.addr, align 4
+  call void @llvm.dbg.declare(metadata ptr %y.addr, metadata !37, metadata !DIExpression()), !dbg !38
+  br label %while.cond, !dbg !39
+
+while.cond:                                       ; preds = %while.body, %entry
+  %0 = load i32, ptr %x.addr, align 4, !dbg !40
+  %1 = load i32, ptr %y.addr, align 4, !dbg !42
+  %cmp = icmp ne i32 %0, %1, !dbg !43
+  br i1 %cmp, label %while.body, label %while.end, !dbg !44
+
+while.body:                                       ; preds = %while.cond
+  call void @_Z6printfv(), !dbg !45
+  %2 = load i32, ptr %y.addr, align 4, !dbg !47
+  %inc = add nsw i32 %2, 1, !dbg !47
+  store i32 %inc, ptr %y.addr, align 4, !dbg !47
+  br label %while.cond, !dbg !48, !llvm.loop !50
+
+while.end:                                        ; preds = %while.cond
+  %3 = load i32, ptr %y.addr, align 4, !dbg !52
+  %conv = sext i32 %3 to i64, !dbg !52
+  ret i64 %conv, !dbg !53
+}
+
+; Function Attrs: mustprogress noinline norecurse uwtable
+define dso_local noundef i32 @main() #3 !dbg !54 {
+entry:
+  %retval = alloca i32, align 4
+  %x = alloca i32, align 4
+  %y = alloca i32, align 4
+  store i32 0, ptr %retval, align 4
+  call void @llvm.dbg.declare(metadata ptr %x, metadata !57, metadata !DIExpression()), !dbg !58
+  store i32 5678, ptr %x, align 4, !dbg !58
+  call void @llvm.dbg.declare(metadata ptr %y, metadata !59, metadata !DIExpression()), !dbg !60
+  store i32 1234, ptr %y, align 4, !dbg !60
+  %0 = load i32, ptr %x, align 4, !dbg !61
+  %1 = load i32, ptr %y, align 4, !dbg !62
+  %call = call noundef i64 @_Z4foo1ii(i32 noundef %0, i32 noundef %1), !dbg !63
+  %2 = load i32, ptr %x, align 4, !dbg !64
+  %conv = sext i32 %2 to i64, !dbg !64
+  %add = add nsw i64 %conv, %call, !dbg !64
+  %conv1 = trunc i64 %add to i32, !dbg !64
+  store i32 %conv1, ptr %x, align 4, !dbg !64
+  %3 = load i32, ptr %x, align 4, !dbg !65
+  %4 = load i32, ptr %y, align 4, !dbg !66
+  %call2 = call noundef i64 @_Z4foo2ii(i32 noundef %3, i32 noundef %4), !dbg !67
+  %5 = load i32, ptr %x, align 4, !dbg !68
+  %conv3 = sext i32 %5 to i64, !dbg !68
+  %add4 = add nsw i64 %conv3, %call2, !dbg !68
+  %conv5 = trunc i64 %add4 to i32, !dbg !68
+  store i32 %conv5, ptr %x, align 4, !dbg !68
+  %6 = load i32, ptr %x, align 4, !dbg !69
+  ret i32 %6, !dbg !70
+}
+
+attributes #0 = { mustprogress noinline uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "use-sample-profile"}
+attributes #1 = { nocallback nofree nosync nounwind readnone speculatable willreturn }
+attributes #2 = { "frame-pointer"="all" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
+attributes #3 = { mustprogress noinline norecurse uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "use-sample-profile"}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!2, !3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang version 15.0.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, splitDebugInlining: false, debugInfoForProfiling: true, nameTableKind: None)
+!1 = !DIFile(filename: "MisNoInline.cpp", directory: ".")
+!2 = !{i32 7, !"Dwarf Version", i32 5}
+!3 = !{i32 2, !"Debug Info Version", i32 3}
+!4 = !{i32 1, !"wchar_size", i32 4}
+!5 = !{i32 7, !"uwtable", i32 2}
+!6 = !{i32 7, !"frame-pointer", i32 2}
+!7 = !{!"clang version 15.0.0"}
+!8 = distinct !DISubprogram(name: "foo1", linkageName: "_Z4foo1ii", scope: !1, file: !1, line: 11, type: !9, scopeLine: 11, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !13)
+!9 = !DISubroutineType(types: !10)
+!10 = !{!11, !12, !12}
+!11 = !DIBasicType(name: "long", size: 64, encoding: DW_ATE_signed)
+!12 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!13 = !{}
+!14 = !DILocalVariable(name: "x", arg: 1, scope: !8, file: !1, line: 11, type: !12)
+!15 = !DILocation(line: 11, column: 41, scope: !8)
+!16 = !DILocalVariable(name: "y", arg: 2, scope: !8, file: !1, line: 11, type: !12)
+!17 = !DILocation(line: 11, column: 48, scope: !8)
+!18 = !DILocation(line: 12, column: 3, scope: !8)
+!19 = !DILocation(line: 12, column: 10, scope: !20)
+!20 = !DILexicalBlockFile(scope: !8, file: !1, discriminator: 2)
+!21 = !DILocation(line: 12, column: 15, scope: !20)
+!22 = !DILocation(line: 12, column: 12, scope: !20)
+!23 = !DILocation(line: 12, column: 3, scope: !20)
+!24 = !DILocation(line: 13, column: 5, scope: !25)
+!25 = distinct !DILexicalBlock(scope: !8, file: !1, line: 12, column: 18)
+!26 = !DILocation(line: 14, column: 6, scope: !25)
+!27 = !DILocation(line: 12, column: 3, scope: !28)
+!28 = !DILexicalBlockFile(scope: !8, file: !1, discriminator: 4)
+!29 = distinct !{!29, !18, !30, !31}
+!30 = !DILocation(line: 15, column: 3, scope: !8)
+!31 = !{!"llvm.loop.mustprogress"}
+!32 = !DILocation(line: 16, column: 10, scope: !8)
+!33 = !DILocation(line: 16, column: 3, scope: !8)
+!34 = distinct !DISubprogram(name: "foo2", linkageName: "_Z4foo2ii", scope: !1, file: !1, line: 18, type: !9, scopeLine: 18, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !13)
+!35 = !DILocalVariable(name: "x", arg: 1, scope: !34, file: !1, line: 18, type: !12)
+!36 = !DILocation(line: 18, column: 41, scope: !34)
+!37 = !DILocalVariable(name: "y", arg: 2, scope: !34, file: !1, line: 18, type: !12)
+!38 = !DILocation(line: 18, column: 48, scope: !34)
+!39 = !DILocation(line: 19, column: 3, scope: !34)
+!40 = !DILocation(line: 19, column: 10, scope: !41)
+!41 = !DILexicalBlockFile(scope: !34, file: !1, discriminator: 2)
+!42 = !DILocation(line: 19, column: 15, scope: !41)
+!43 = !DILocation(line: 19, column: 12, scope: !41)
+!44 = !DILocation(line: 19, column: 3, scope: !41)
+!45 = !DILocation(line: 20, column: 5, scope: !46)
+!46 = distinct !DILexicalBlock(scope: !34, file: !1, line: 19, column: 18)
+!47 = !DILocation(line: 21, column: 6, scope: !46)
+!48 = !DILocation(line: 19, column: 3, scope: !49)
+!49 = !DILexicalBlockFile(scope: !34, file: !1, discriminator: 4)
+!50 = distinct !{!50, !39, !51, !31}
+!51 = !DILocation(line: 22, column: 3, scope: !34)
+!52 = !DILocation(line: 23, column: 10, scope: !34)
+!53 = !DILocation(line: 23, column: 3, scope: !34)
+!54 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 25, type: !55, scopeLine: 25, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !13)
+!55 = !DISubroutineType(types: !56)
+!56 = !{!12}
+!57 = !DILocalVariable(name: "x", scope: !54, file: !1, line: 26, type: !12)
+!58 = !DILocation(line: 26, column: 7, scope: !54)
+!59 = !DILocalVariable(name: "y", scope: !54, file: !1, line: 27, type: !12)
+!60 = !DILocation(line: 27, column: 7, scope: !54)
+!61 = !DILocation(line: 28, column: 13, scope: !54)
+!62 = !DILocation(line: 28, column: 16, scope: !54)
+!63 = !DILocation(line: 28, column: 8, scope: !54)
+!64 = !DILocation(line: 28, column: 5, scope: !54)
+!65 = !DILocation(line: 29, column: 13, scope: !54)
+!66 = !DILocation(line: 29, column: 16, scope: !54)
+!67 = !DILocation(line: 29, column: 8, scope: !54)
+!68 = !DILocation(line: 29, column: 5, scope: !54)
+!69 = !DILocation(line: 31, column: 10, scope: !54)
+!70 = !DILocation(line: 31, column: 3, scope: !54)