[llvm] [ARM] Specify inlining behavior in TableGen (PR #205763)

[David Green via llvm-commits]

================
@@ -528,29 +575,37 @@ def FeatureLOB            : SubtargetFeature<"lob", "HasLOB", "true",
                                              "extensions">;
 
 // Mitigate against the cve-2021-35465 security vulnurability.
+// TODO: Does this need to be InlineMustMatch?
 def FeatureFixCMSE_CVE_2021_35465 : SubtargetFeature<"fix-cmse-cve-2021-35465",
                                         "FixCMSE_CVE_2021_35465", "true",
                                         "Mitigate against the cve-2021-35465 "
-                                        "security vulnurability">;
+                                        "security vulnurability",
+                                        [], InlineMustMatch>;
 
+// TODO: Does this need to be InlineMustMatch?
 def FeaturePACBTI         : SubtargetFeature<"pacbti", "HasPACBTI", "true",
                                              "Enable Pointer Authentication and Branch "
-                                             "Target Identification">;
+                                             "Target Identification",
+                                             [], InlineMustMatch>;
 
 /// Don't place a BTI instruction after return-twice constructs (setjmp).
+// TODO: Does this need to be InlineMustMatch?
 def FeatureNoBTIAtReturnTwice : SubtargetFeature<"no-bti-at-return-twice",
                                                  "NoBTIAtReturnTwice", "true",
                                                  "Don't place a BTI instruction "
-                                                 "after a return-twice">;
+                                                 "after a return-twice",
+                                                 [], InlineMustMatch>;
----------------
davemgreen wrote:

I am not.

I don't think I would ever expect them to be different inside the same project. They are really two different schemes depending on the libraries being used. I am assuming that if they are different, the no-bti-at-return-twice was probably on purpose and the one without was probably a mistake. So inlining into a function with no-bti-at-return-twice in that regard is probably fine.

I don't mind being conservative (if we call InlineMustMatch conservative), as I don't expect it to come up on purpose.

https://github.com/llvm/llvm-project/pull/205763