[clang][slh] add Clang attr no_speculative_load_hardening

[zbrid]

Summary

This attribute will allow users to opt specific functions out of
speculative load hardening. This compliments the Clang attribute
named speculative_load_hardening. When this attribute or the attribute
speculative_load_hardening is used in combination with the flags
-mno-speculative-load-hardening or -mspeculative-load-hardening,
the function level attribute will override the default during LLVM IR
generation. For example, in the case, where the flag opposes the
function attribute, the function attribute will take precendence.
The sticky inlining behavior of the speculative_load_hardening attribute
may cause a function with the no_speculative_load_hardening attribute
to be tagged with the speculative_load_hardening tag in
subsequent compiler phases which is desired behavior since the
speculative_load_hardening LLVM attribute is designed to be maximally
conservative.

[zbrid]

I need to work on this some more.

[zbrid]

Add tests and documentation

[zbrid]

@aaron.ballman @kristof.beyls ping

[kristof.beyls]

clang/include/clang/Basic/AttrDocs.td

3776

Hi Zola,

I'm afraid I don't have time for an in-depth look in the next few days,
but I wonder if you have an answer to the follow higher-level question.
I wonder why not define no_speculative_load_hardening as giving a
guarantee that speculative load hardening doesn't happen on the code.
I'm not sure if there are users of this attribute that need the
guarantee that speculative load hardening doesn't happen, but there may?
I guess that to implement such behaviour, it would require also introducing a
no_speculative_load_hardening attribute at the LLVM-IR level?
Or somehow (I don't know if that's possible) make the existing
speculative_load_hardening attribute at LLVM-IR level have 3 potential
states: "no hardening", "must harden" and "don't care".
I guess the current proposed behaviour is because that's easier to implement,
or is there another reason?
What do you think?

Thanks,

Kristof

[chandlerc]

clang/include/clang/Basic/AttrDocs.td

3772

Maybe say "is not needed for the function body" to make it more clear?

3776

FWIW, I had suggested this design because I think it is simple, and addresses the only use case I have in mind.

That use case is essentially to remove SLH from functions that are performance sensitive and manually mitigated (if at risk at all). The intent is that people can use this based on profiling to recover some performance hit from SLH where it is safe to do so. As a consequence, the goal was not what you describe.

My thought process goes like this:

• Some routines may explicitly opt into SLH because they are at unusual risk. There is an attribute to do this. This attribute always wins: the code with the attribute is *never* allowed to be emitted w/o the hardening.
• Other routines may opt *out* of SLH if it is enabled on the command line, much like routines may opt out of sanitizer instrumentation.
• Everything else picks up whichever default is selected at the command line.

Now, we have to deal with what happens if the inliner tries to inline a function marked with an explicit attribute into code marked with this no_speculative_load_hardening attribute. I don't expect this to ever realistically occur, but we need to handle it if it does. Sadly, we can't just produce an error -- the backend may be the only thing that sees this. We could add an LLVM attribute as you suggest and block inlining in this case, but that seems very intrusive and is only designed to handle an edge case that we don't anticipate happens much if ever in practice. The final option which seems the most reasonable is what this implements: the positive attribute always wins. IMO, this is a reasonable handling of the edge case, and keeps things as simple as possible.

[aaron.ballman]

clang/include/clang/Basic/AttrDocs.td

3749

Add backticks around the command line flag. Bonus points if you can link it to the command line documentation for that command.

3772

Also, use RST formatting for NOT rather than capitalizing it. (Either surround it like *this* for italics or like this for bold.)

3776

I think the current design is the right approach, but I'd appreciate seeing a code example in the documentation that more clearly shows the expectation. Something like:

__attribute__((speculative_load_hardening)) int foo(int i) { return i; }
__attribute__((no_speculative_load_hardening)) int bar(int i) {
  // Note: bar() may still have speculative load hardening if foo() is
  // inlined into bar(). Mark foo() with __attribute__((noinline)) to
  // avoid this situation.
  return foo(i);
}

Feel free to devise a less terrible example, too. ;-)

One question I have is: do we think it's worth diagnosing this slightly different case, given that the user has signaled explicitly that they want foo() inlined, but the call is has speculative load hardening disabled:

__attribute__((speculative_load_hardening)) inline int foo(int i) { return i; }
__attribute__((no_speculative_load_hardening)) int bar(int i) {
  return foo(i); // Warning?
}

[kristof.beyls]

clang/include/clang/Basic/AttrDocs.td

3776

Thanks for explaining the detailed rationale.

Referring to: "Now, we have to deal with what happens if the inliner tries to inline a function marked with an explicit attribute into code marked with this no_speculative_load_hardening attribute." , which is the case of "SLH-function ---inline into---> noSLH-function".
I'm assuming you don't call out the reverse "noSLH-function ---inline into---> SLH-function" situation as you can mark the noSLH-function with a noinline attribute if you really want to prevent SLH to be applied to the code in the noSLH-function.

Overall, I agree that it doesn't seem worthwhile to introduce the extra complexity needed for that remaining "SLH-function ---inline into----> noSLH-function" theoretical edge case.
Or in other words, you've convinced me the design tradeoffs in this patch are right.

[zbrid]

Update documentation based on review comments.

[zbrid]

Fix indentation of code block in attribute documentation for no speculative load hardening

[aaron.ballman]

clang/include/clang/Basic/AttrDocs.td

3786

I think this is meant to be .. code-block:: c ?

clang/test/SemaCXX/attr-no-speculative-load-hardening.cpp

6

Should this situation be diagnosed?

__attribute__((no_speculative_load_hardening))
void func();

__attribute__((speculative_load_hardening))
void func();

Which attribute should "win"?

If you want to diagnose, you can use checkAttrMutualExclusion() to handle this in SemaDeclAttr.cpp.

[zbrid]

detect (some, not yet all) incompatible uses of attrs; move tests to correct folders

[zbrid]

clang/include/clang/Basic/AttrDocs.td

3776

@aaron.ballman I will try to implement a warning like you proposed for that particular case. Still looking into it., but wanted to ack.

clang/test/SemaCXX/attr-speculative-load-hardening.cpp

19 ↗

(On Diff #178526)

Should this situation be diagnosed?

attribute((no_speculative_load_hardening))
void func();

attribute((speculative_load_hardening))
void func();
Which attribute should "win"?

If you want to diagnose, you can use checkAttrMutualExclusion() to handle this in SemaDeclAttr.cpp.

@aaron.ballman
That's a great idea. So far I've added the use of checkAttrMutualExclusion which catches the cases in this test and the three added below. I'm working on a change that will catch the case in your example. I think I'll have to make a change in Clang to check for mutual exclusion when the attributes are merged rather than where they are currently checked. I don't have all the details yet, but I think I'll send a separate patch for that once I figure out what's going on.

[zbrid]

clang/test/SemaCXX/attr-speculative-load-hardening.cpp

19 ↗

(On Diff #178526)

After looking more closely at this, I think I only need to write a function for this particular attribute to be merged differently than the default way which will cause the diagnostic if necessary in this case which is a smaller change than I thought, so I'll add the change to this patch.

[zbrid]

Give an error when a function was both attributes specified at different places in the code.

[zbrid]

rebase

[aaron.ballman]

LGTM aside from a minor formatting question.

clang/lib/Sema/SemaDeclAttr.cpp

4135–4136

Is this the formatting you get from clang-format?

[zbrid]

clang format

[zbrid]

more clang format

[zbrid]

[slh] add clang diagnostic

[zbrid]

clang/lib/Sema/SemaDecl.cpp

13079 ↗

(On Diff #180575)

@aaron.ballman Could you take a look at this clang diagnostic I added for the case you suggested in another comment?

[aaron.ballman]

clang/include/clang/Sema/Sema.h

1718–1719 ↗

(On Diff #180575)

You should give these parameters identifiers to help people reading the source code understand what should be passed for each argument.

clang/lib/Sema/SemaDecl.cpp

13080–13081 ↗

(On Diff #180575)

The identifiers don't match the usual naming conventions (here and elsewhere).

13082 ↗

(On Diff #180575)

I would turn this into an early return rather than indent the entire function body one level for it.

13087–13089 ↗

(On Diff #180575)

llvm::copy(Node->children(), std::back_inserter(Nodes));

13090 ↗

(On Diff #180575)

Should be const auto * (same below) rather than inferring the const qualification.

Moreover, this seems incorrect -- you don't mean any declref to an attributed function, do you? I would have imagined that only call expressions matter. e.g., this should not diagnose:

[[clang::speculative_load_hardening]] inline int bar(int x) { return x; }

[[clang::no_speculative_load_hardening]] int foo() {
  if (bar) {  // No reason to warn about speculative load hardening because there's no call.
  }
  return sizeof(bar(0)); // Unevaluated expression probably doesn't need a warning either.
}

I'm a bit concerned about the performance cost of touching every child AST node in the function body. I wonder if it would be possible to check CallExprs as they're handled instead? I'm not certain if there's a way to get from the Expr to the context in which the expression appears so that we can see if the expression is within a function with speculative load hardening disabled or not, so this may be a dead-end idea.

If it turns out that handling it at the CallExpr site isn't feasible, then I think we should probably revert this diagnostic and go with the previous version of the patch. We can take another swing at a diagnostic if we find that people actually hit this corner case often enough to warrant the extra expense of the check (or we can solve it another way, through clang-tidy or the static analyzer). WDYT?

13096 ↗

(On Diff #180575)

You should pass in ND and Callee directly rather than calling getName() on them; the diagnostic engine will handle properly quoting the name that's output as well.

13129 ↗

(On Diff #180575)

Why are you qualifying the call?

13294 ↗

(On Diff #180575)

Spurious change?

[zbrid]

clang/lib/Sema/SemaDecl.cpp

13090 ↗

(On Diff #180575)

I looked into handling this at the CallExpr site and it looks like the context needed for this diagnostic is available. I'll update the patch when I get that version working. That suggestion makes a lot of sense to me.

As for checking every DeclRefExpr, that was due to my misunderstanding of the AST. Given what you said, I think what I really want are the DeclRefExpr that are children of CallExpr. That'll be reflected in the updated patch.

I'll keep all these style comments in mind when making the update too.

13294 ↗

(On Diff #180575)

Yes, I'll revert that.

[zbrid]

[clang][slh] remove diagnostic for now

[zbrid]

[clang][slh] delete stray includes from removed code

[zbrid]

I'm going to revert the diagnostic changes for now and commit this patch. I tried a few ways to implement this without success so far. I have one additional way I want to try based on some advice on the cfe-dev list, but I'll submit it in another patch once I get some time to try and implement it.

[aaron.ballman]

In D54909#1359919, @zbrid wrote:

I'm going to revert the diagnostic changes for now and commit this patch. I tried a few ways to implement this without success so far. I have one additional way I want to try based on some advice on the cfe-dev list, but I'll submit it in another patch once I get some time to try and implement it.

That sounds reasonable to me -- I didn't intend for it to hold your patch up; it can always be done separately.

clang/include/clang/Basic/Attr.td

def AlwaysDestroy : InheritableAttr {
   let Documentation = [AlwaysDestroyDocs];
 }
 
 def SpeculativeLoadHardening : InheritableAttr {
   let Spellings = [Clang<"speculative_load_hardening">];
   let Subjects = SubjectList<[Function, ObjCMethod], ErrorDiag>;
   let Documentation = [SpeculativeLoadHardeningDocs];
 }
+
+def NoSpeculativeLoadHardening : InheritableAttr {
+  let Spellings = [Clang<"no_speculative_load_hardening">];
+  let Subjects = SubjectList<[Function, ObjCMethod], ErrorDiag>;
+  let Documentation = [NoSpeculativeLoadHardeningDocs];
+}

clang/include/clang/Basic/AttrDocs.td

 }
 
 def SpeculativeLoadHardeningDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
   This attribute can be applied to a function declaration in order to indicate
   that `Speculative Load Hardening <https://llvm.org/docs/SpeculativeLoadHardening.html>`_
   should be enabled for the function body. This can also be applied to a method
-  in Objective C.
+  in Objective C. This attribute will take precedence over the command line flag in
+  the case where `-mno-speculative-load-hardening <https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mspeculative-load-hardening>`_ is specified.
 
   Speculative Load Hardening is a best-effort mitigation against
   information leak attacks that make use of control flow
   miss-speculation - specifically miss-speculation of whether a branch
   is taken or not. Typically vulnerabilities enabling such attacks are
   classified as "Spectre variant #1". Notably, this does not attempt to
   mitigate against miss-speculation of branch target, classified as
   "Spectre variant #2" vulnerabilities.
 
   When inlining, the attribute is sticky. Inlining a function that
   carries this attribute will cause the caller to gain the
   attribute. This is intended to provide a maximally conservative model
   where the code in a function annotated with this attribute will always
   (even after inlining) end up hardened.
   }];
 }
+
+def NoSpeculativeLoadHardeningDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+  This attribute can be applied to a function declaration in order to indicate
+  that `Speculative Load Hardening <https://llvm.org/docs/SpeculativeLoadHardening.html>`_
+  is *not* needed for the function body. This can also be applied to a method
+  in Objective C. This attribute will take precedence over the command line flag in
+  the case where `-mspeculative-load-hardening <https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mspeculative-load-hardening>`_ is specified.
+
+  Warning: This attribute may not prevent Speculative Load Hardening from being
+  enabled for a function which inlines a function that has the
+  'speculative_load_hardening' attribute. This is intended to provide a
+  maximally conservative model where the code that is marked with the
+  'speculative_load_hardening' attribute will always (even when inlined)
+  be hardened. A user of this attribute may want to mark functions called by
+  a function they do not want to be hardened with the 'noinline' attribute.
+
+  For example:
+
+  ::
+
+  __attribute__((speculative_load_hardening))
+  int foo(int i) {
+    return i;
+  }
+
+  // Note: bar() may still have speculative load hardening enabled if
+  // foo() is inlined into bar(). Mark foo() with __attribute__((noinline))
+  // to avoid this situation.
+  __attribute__((no_speculative_load_hardening))
+  int bar(int i) {
+    return foo(i);
+  }
+  }];
+}

clang/lib/CodeGen/CGCall.cpp

if (!CodeGenOpts.PreferVectorWidth.empty() &&
       FuncAttrs.addAttribute("prefer-vector-width",
                              CodeGenOpts.PreferVectorWidth);
 
     if (CodeGenOpts.StackRealignment)
       FuncAttrs.addAttribute("stackrealign");
     if (CodeGenOpts.Backchain)
       FuncAttrs.addAttribute("backchain");
 
-    // FIXME: The interaction of this attribute with the SLH command line flag
-    // has not been determined.
     if (CodeGenOpts.SpeculativeLoadHardening)
       FuncAttrs.addAttribute(llvm::Attribute::SpeculativeLoadHardening);
   }
 
   if (getLangOpts().assumeFunctionsAreConvergent()) {
     // Conservatively, mark all functions and calls in CUDA and OpenCL as
     // convergent (meaning, they may call an intrinsically convergent op, such
     // as __syncthreads() / barrier(), and so can't have certain optimizations
if (TargetDecl) {
     if (TargetDecl->hasAttr<NoReturnAttr>())
       FuncAttrs.addAttribute(llvm::Attribute::NoReturn);
     if (TargetDecl->hasAttr<ColdAttr>())
       FuncAttrs.addAttribute(llvm::Attribute::Cold);
     if (TargetDecl->hasAttr<NoDuplicateAttr>())
       FuncAttrs.addAttribute(llvm::Attribute::NoDuplicate);
     if (TargetDecl->hasAttr<ConvergentAttr>())
       FuncAttrs.addAttribute(llvm::Attribute::Convergent);
-    if (TargetDecl->hasAttr<SpeculativeLoadHardeningAttr>())
-      FuncAttrs.addAttribute(llvm::Attribute::SpeculativeLoadHardening);
 
     if (const FunctionDecl *Fn = dyn_cast<FunctionDecl>(TargetDecl)) {
       AddAttributesFromFunctionProtoType(
           getContext(), FuncAttrs, Fn->getType()->getAs<FunctionProtoType>());
       // Don't use [[noreturn]] or _Noreturn for a call to a virtual function.
       // These attributes are not inherited by overloads.
       const CXXMethodDecl *MD = dyn_cast<CXXMethodDecl>(Fn);
       if (Fn->isNoReturn() && !(AttrOnCallSite && MD && MD->isVirtual()))
if (auto *AllocSize = TargetDecl->getAttr<AllocSizeAttr>()) {
         NumElemsParam = AllocSize->getNumElemsParam().getLLVMIndex();
       FuncAttrs.addAllocSizeAttr(AllocSize->getElemSizeParam().getLLVMIndex(),
                                  NumElemsParam);
     }
   }
 
   ConstructDefaultFnAttrList(Name, HasOptnone, AttrOnCallSite, FuncAttrs);
 
+  // This must run after constructing the default function attribute list
+  // to ensure that the speculative load hardening attribute is removed
+  // in the case where the -mspeculative-load-hardening flag was passed.
+  if (TargetDecl) {
+    if (TargetDecl->hasAttr<NoSpeculativeLoadHardeningAttr>())
+      FuncAttrs.removeAttribute(llvm::Attribute::SpeculativeLoadHardening);
+    if (TargetDecl->hasAttr<SpeculativeLoadHardeningAttr>())
+      FuncAttrs.addAttribute(llvm::Attribute::SpeculativeLoadHardening);
+   }
+
   if (CodeGenOpts.EnableSegmentedStacks &&
       !(TargetDecl && TargetDecl->hasAttr<NoSplitStackAttr>()))
     FuncAttrs.addAttribute("split-stack");
 
   // Add NonLazyBind attribute to function declarations when -fno-plt
   // is used.
   if (TargetDecl && CodeGenOpts.NoPLT) {
     if (auto *Fn = dyn_cast<FunctionDecl>(TargetDecl)) {

clang/lib/Sema/SemaDeclAttr.cpp

MinSizeAttr *Sema::mergeMinSizeAttr(Decl *D, SourceRange Range,
   }
 
   if (D->hasAttr<MinSizeAttr>())
     return nullptr;
 
   return ::new (Context) MinSizeAttr(Range, Context, AttrSpellingListIndex);
 }
 
 OptimizeNoneAttr *Sema::mergeOptimizeNoneAttr(Decl *D, SourceRange Range,
                                               unsigned AttrSpellingListIndex) {
   if (AlwaysInlineAttr *Inline = D->getAttr<AlwaysInlineAttr>()) {
     Diag(Inline->getLocation(), diag::warn_attribute_ignored) << Inline;
     Diag(Range.getBegin(), diag::note_conflicting_attribute);
     D->dropAttr<AlwaysInlineAttr>();
   }
   if (MinSizeAttr *MinSize = D->getAttr<MinSizeAttr>()) {
     Diag(MinSize->getLocation(), diag::warn_attribute_ignored) << MinSize;
     Diag(Range.getBegin(), diag::note_conflicting_attribute);
case ParsedAttr::AT_Packed:
     handlePackedAttr(S, D, AL);
     break;
   case ParsedAttr::AT_Section:
     handleSectionAttr(S, D, AL);
     break;
   case ParsedAttr::AT_SpeculativeLoadHardening:
     handleSimpleAttribute<SpeculativeLoadHardeningAttr>(S, D, AL);
     break;
+  case ParsedAttr::AT_NoSpeculativeLoadHardening:
+    handleSimpleAttribute<NoSpeculativeLoadHardeningAttr>(S, D, AL);
+    break;
   case ParsedAttr::AT_CodeSeg:
     handleCodeSegAttr(S, D, AL);
     break;
   case ParsedAttr::AT_Target:
     handleTargetAttr(S, D, AL);
     break;
   case ParsedAttr::AT_MinVectorWidth:
     handleMinVectorWidthAttr(S, D, AL);

clang/test/CodeGen/attr-speculative-load-hardening.cpp

+// Check that we correctly set or did not set the attribute for each function.
 // RUN: %clang_cc1 -std=c++11 -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK1
 // RUN: %clang_cc1 -std=c++11 -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK2
-//
-// Check that we set the attribute on each function.
+
+// Check that we correctly set or did not set the attribute on each function despite the
+// -mspeculative-load-hardening flag.
+// RUN: %clang_cc1 -mspeculative-load-hardening -std=c++11 -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK3
+// RUN: %clang_cc1 -mspeculative-load-hardening -std=c++11 -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK4
+
+
+// Check that we correctly set or did not set the attribute on each function despite the
+// -mno-speculative-load-hardening flag.
+// RUN: %clang -mno-speculative-load-hardening -S -std=c++11 -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK5
+// RUN: %clang -mno-speculative-load-hardening -S -std=c++11 -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK6
+
 
 [[clang::speculative_load_hardening]]
 int test1() {
   return 42;
 }
 
 int __attribute__((speculative_load_hardening)) test2() {
   return 42;
 }
-// CHECK1: @{{.*}}test1{{.*}}[[SLH1:#[0-9]+]]
-// CHECK1: attributes [[SLH1]] = { {{.*}}speculative_load_hardening{{.*}} }
 
-// CHECK2: @{{.*}}test2{{.*}}[[SLH2:#[0-9]+]]
-// CHECK2: attributes [[SLH2]] = { {{.*}}speculative_load_hardening{{.*}} }
+[[clang::no_speculative_load_hardening]]
+int test3() {
+  return 42;
+}
+
+int __attribute__((no_speculative_load_hardening)) test4() {
+  return 42;
+}
+// CHECK1: @{{.*}}test1{{.*}}[[SLH:#[0-9]+]]
+// CHECK1: @{{.*}}test3{{.*}}[[NOSLH:#[0-9]+]]
+// CHECK1: attributes [[SLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+// CHECK1-NOT: attributes [[NOSLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+
+// CHECK2: @{{.*}}test2{{.*}}[[SLH:#[0-9]+]]
+// CHECK2: @{{.*}}test4{{.*}}[[NOSLH:#[0-9]+]]
+// CHECK2: attributes [[SLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+// CHECK2-NOT: attributes [[NOSLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+
+// CHECK3: @{{.*}}test1{{.*}}[[SLH:#[0-9]+]]
+// CHECK3: @{{.*}}test3{{.*}}[[NOSLH:#[0-9]+]]
+// CHECK3: attributes [[SLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+// CHECK3-NOT: attributes [[NOSLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+
+// CHECK4: @{{.*}}test2{{.*}}[[SLH:#[0-9]+]]
+// CHECK4: @{{.*}}test4{{.*}}[[NOSLH:#[0-9]+]]
+// CHECK4: attributes [[SLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+// CHECK4-NOT: attributes [[NOSLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+
+// CHECK5: @{{.*}}test1{{.*}}[[SLH:#[0-9]+]]
+// CHECK5: @{{.*}}test3{{.*}}[[NOSLH:#[0-9]+]]
+// CHECK5: attributes [[SLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+// CHECK5-NOT: attributes [[NOSLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+
+// CHECK6: @{{.*}}test2{{.*}}[[SLH:#[0-9]+]]
+// CHECK6: @{{.*}}test4{{.*}}[[NOSLH:#[0-9]+]]
+// CHECK6: attributes [[SLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+// CHECK6-NOT: attributes [[NOSLH]] = { {{.*}}speculative_load_hardening{{.*}} }

clang/test/CodeGen/attr-speculative-load-hardening.m

 // RUN: %clang -emit-llvm %s -o - -S | FileCheck %s -check-prefix=SLH
 
 int main() __attribute__((speculative_load_hardening)) {
   return 0;
 }
 
-// SLH: @{{.*}}main{{.*}}[[SLH:#[0-9]+]]
+int test() __attribute__((no_speculative_load_hardening)) {
+  return 0;
+}
 
+// SLH: @{{.*}}main{{.*}}[[SLH:#[0-9]+]]
+// SLH: @{{.*}}test{{.*}}[[NOSLH:#[0-9]+]]
 // SLH: attributes [[SLH]] = { {{.*}}speculative_load_hardening{{.*}} }
+// SLH-NOT: attributes [[NOSLH]] = { {{.*}}speculative_load_hardening{{.*}} }

clang/test/Misc/pragma-attribute-supported-attributes-list.test

 // CHECK-NEXT: NoDuplicate (SubjectMatchRule_function)
 // CHECK-NEXT: NoEscape (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: NoInline (SubjectMatchRule_function)
 // CHECK-NEXT: NoInstrumentFunction (SubjectMatchRule_function)
 // CHECK-NEXT: NoMicroMips (SubjectMatchRule_function)
 // CHECK-NEXT: NoMips16 (SubjectMatchRule_function)
 // CHECK-NEXT: NoSanitize (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_variable_is_global)
 // CHECK-NEXT: NoSanitizeSpecific (SubjectMatchRule_function, SubjectMatchRule_variable_is_global)
+// CHECK-NEXT: NoSpeculativeLoadHardening (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: NoSplitStack (SubjectMatchRule_function)
 // CHECK-NEXT: NoStackProtector (SubjectMatchRule_function)
 // CHECK-NEXT: NoThreadSafetyAnalysis (SubjectMatchRule_function)
 // CHECK-NEXT: NoThrow (SubjectMatchRule_function)
 // CHECK-NEXT: NotTailCalled (SubjectMatchRule_function)
 // CHECK-NEXT: OSConsumed (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: OSReturnsNotRetained (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property)
 // CHECK-NEXT: OSReturnsRetained (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property)

clang/test/SemaCXX/attr-no-speculative-load-hardening.cpp

+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify %s
+
+int i __attribute__((no_speculative_load_hardening)); // expected-error {{'no_speculative_load_hardening' attribute only applies to functions}}
+
+void f1() __attribute__((no_speculative_load_hardening));
+void f2() __attribute__((no_speculative_load_hardening(1))); // expected-error {{'no_speculative_load_hardening' attribute takes no arguments}}
+
+template <typename T>
+void tf1() __attribute__((no_speculative_load_hardening));
+
+int f3(int __attribute__((no_speculative_load_hardening)), int); // expected-error {{'no_speculative_load_hardening' attribute only applies to functions}}
+
+struct A {
+  int f __attribute__((no_speculative_load_hardening));  // expected-error {{'no_speculative_load_hardening' attribute only applies to functions}}
+  void mf1() __attribute__((no_speculative_load_hardening));
+  static void mf2() __attribute__((no_speculative_load_hardening));
+};
+
+int ci [[clang::no_speculative_load_hardening]]; // expected-error {{'no_speculative_load_hardening' attribute only applies to functions}}
+
+[[clang::no_speculative_load_hardening]] void cf1();
+[[clang::no_speculative_load_hardening(1)]] void cf2(); // expected-error {{'no_speculative_load_hardening' attribute takes no arguments}}
+
+template <typename T>
+[[clang::no_speculative_load_hardening]]
+void ctf1();
+
+int cf3(int c[[clang::no_speculative_load_hardening]], int); // expected-error {{'no_speculative_load_hardening' attribute only applies to functions}}
+
+struct CA {
+  int f [[clang::no_speculative_load_hardening]];  // expected-error {{'no_speculative_load_hardening' attribute only applies to functions}}
+  [[clang::no_speculative_load_hardening]] void mf1();
+  [[clang::no_speculative_load_hardening]] static void mf2();
+};