maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Sema/attr-coldhot.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

19 lines
1.1 KiB
C
Raw Normal View History

Add support for __attribute__((hot)) and __attribute__((cold)). Currently cold functions are marked with the "optsize" attribute in CodeGen so they are always optimized for size. The hot attribute is just ignored, LLVM doesn't have a way to express hotness at the moment. llvm-svn: 156723
2012-05-13 05:10:52 +08:00
// RUN: %clang_cc1 -fsyntax-only -verify %s
int foo() __attribute__((__hot__));
int bar() __attribute__((__cold__));
int var1 __attribute__((__cold__)); // expected-warning{{'__cold__' attribute only applies to functions}}
int var2 __attribute__((__hot__)); // expected-warning{{'__hot__' attribute only applies to functions}}
Append new attributes to the end of an AttributeList. Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
2018-08-03 09:21:16 +08:00
int qux() __attribute__((__hot__)) __attribute__((__cold__)); // expected-error{{'__cold__' and 'hot' attributes are not compatible}} \
Implement __attribute__((internal_linkage)). The attrubite is applicable to functions and variables and changes the linkage of the subject to internal. This is the same functionality as C-style "static", but applicable to class methods; and the same as anonymouns namespaces, but can apply to individual methods of a class. Following the proposal in http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html llvm-svn: 252648
2015-11-11 05:28:44 +08:00
// expected-note{{conflicting attribute is here}}
Append new attributes to the end of an AttributeList. Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
2018-08-03 09:21:16 +08:00
int baz() __attribute__((__cold__)) __attribute__((__hot__)); // expected-error{{'__hot__' and 'cold' attributes are not compatible}} \
Implement __attribute__((internal_linkage)). The attrubite is applicable to functions and variables and changes the linkage of the subject to internal. This is the same functionality as C-style "static", but applicable to class methods; and the same as anonymouns namespaces, but can apply to individual methods of a class. Following the proposal in http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html llvm-svn: 252648
2015-11-11 05:28:44 +08:00
// expected-note{{conflicting attribute is here}}
Use tablegen to diagnose mutually exclusive attributes Currently, when one or more attributes are mutually exclusive, the developer adding the attribute has to manually emit diagnostics. In practice, this is highly error prone, especially for declaration attributes, because such checking is not trivial. Redeclarations require you to write a "merge" function to diagnose mutually exclusive attributes and most attributes get this wrong. This patch introduces a table-generated way to specify that a group of two or more attributes are mutually exclusive: def : MutualExclusions<[Attr1, Attr2, Attr3]>; This works for both statement and declaration attributes (but not type attributes) and the checking is done either from the common attribute diagnostic checking code or from within mergeDeclAttribute() when merging redeclarations.
2021-04-03 04:33:14 +08:00
__attribute__((cold)) void test1(void); // expected-note{{conflicting attribute is here}}
__attribute__((hot)) void test1(void); // expected-error{{'hot' and 'cold' attributes are not compatible}}
__attribute__((hot)) void test2(void); // expected-note{{conflicting attribute is here}}
__attribute__((cold)) void test2(void); // expected-error{{'cold' and 'hot' attributes are not compatible}}