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/arm-mve-alias-attribute.c

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

29 lines
1.3 KiB
C
Raw Normal View History

[clang] New __attribute__((__clang_arm_mve_alias)). This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
2019-09-02 22:35:09 +08:00
// RUN: %clang_cc1 -triple armv8.1m.main-arm-none-eabi -verify -fsyntax-only %s
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE Summary: This patch generalizes the existing code to support CDE intrinsics which will share some properties with existing MVE intrinsics (some of the intrinsics will be polymorphic and accept/return values of MVE vector types). Specifically the patch: * Adds new tablegen backends -gen-arm-cde-builtin-def, -gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema, -gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on existing MVE backends. * Renames the '__clang_arm_mve_alias' attribute into '__clang_arm_builtin_alias' (it will be used with CDE intrinsics as well as MVE intrinsics) * Implements semantic checks for the coprocessor argument of the CDE intrinsics as well as the existing coprocessor intrinsics. * Adds one CDE intrinsic __arm_cx1 to test the above changes Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: simon_tatham Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
static __inline__ __attribute__((__clang_arm_builtin_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_builtin_alias' attribute can only be applied to an ARM builtin}}
void
nop(void);
[clang] New __attribute__((__clang_arm_mve_alias)). This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
2019-09-02 22:35:09 +08:00
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE Summary: This patch generalizes the existing code to support CDE intrinsics which will share some properties with existing MVE intrinsics (some of the intrinsics will be polymorphic and accept/return values of MVE vector types). Specifically the patch: * Adds new tablegen backends -gen-arm-cde-builtin-def, -gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema, -gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on existing MVE backends. * Renames the '__clang_arm_mve_alias' attribute into '__clang_arm_builtin_alias' (it will be used with CDE intrinsics as well as MVE intrinsics) * Implements semantic checks for the coprocessor argument of the CDE intrinsics as well as the existing coprocessor intrinsics. * Adds one CDE intrinsic __arm_cx1 to test the above changes Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: simon_tatham Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
static __inline__ __attribute__((__clang_arm_builtin_alias)) // expected-error {{'__clang_arm_builtin_alias' attribute takes one argument}}
void
noparens(void);
[clang] New __attribute__((__clang_arm_mve_alias)). This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
2019-09-02 22:35:09 +08:00
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE Summary: This patch generalizes the existing code to support CDE intrinsics which will share some properties with existing MVE intrinsics (some of the intrinsics will be polymorphic and accept/return values of MVE vector types). Specifically the patch: * Adds new tablegen backends -gen-arm-cde-builtin-def, -gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema, -gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on existing MVE backends. * Renames the '__clang_arm_mve_alias' attribute into '__clang_arm_builtin_alias' (it will be used with CDE intrinsics as well as MVE intrinsics) * Implements semantic checks for the coprocessor argument of the CDE intrinsics as well as the existing coprocessor intrinsics. * Adds one CDE intrinsic __arm_cx1 to test the above changes Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: simon_tatham Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
static __inline__ __attribute__((__clang_arm_builtin_alias())) // expected-error {{'__clang_arm_builtin_alias' attribute takes one argument}}
void
emptyparens(void);
[clang] New __attribute__((__clang_arm_mve_alias)). This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
2019-09-02 22:35:09 +08:00
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE Summary: This patch generalizes the existing code to support CDE intrinsics which will share some properties with existing MVE intrinsics (some of the intrinsics will be polymorphic and accept/return values of MVE vector types). Specifically the patch: * Adds new tablegen backends -gen-arm-cde-builtin-def, -gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema, -gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on existing MVE backends. * Renames the '__clang_arm_mve_alias' attribute into '__clang_arm_builtin_alias' (it will be used with CDE intrinsics as well as MVE intrinsics) * Implements semantic checks for the coprocessor argument of the CDE intrinsics as well as the existing coprocessor intrinsics. * Adds one CDE intrinsic __arm_cx1 to test the above changes Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: simon_tatham Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
static __inline__ __attribute__((__clang_arm_builtin_alias("string literal"))) // expected-error {{'__clang_arm_builtin_alias' attribute requires parameter 1 to be an identifier}}
void
stringliteral(void);
[clang] New __attribute__((__clang_arm_mve_alias)). This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
2019-09-02 22:35:09 +08:00
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE Summary: This patch generalizes the existing code to support CDE intrinsics which will share some properties with existing MVE intrinsics (some of the intrinsics will be polymorphic and accept/return values of MVE vector types). Specifically the patch: * Adds new tablegen backends -gen-arm-cde-builtin-def, -gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema, -gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on existing MVE backends. * Renames the '__clang_arm_mve_alias' attribute into '__clang_arm_builtin_alias' (it will be used with CDE intrinsics as well as MVE intrinsics) * Implements semantic checks for the coprocessor argument of the CDE intrinsics as well as the existing coprocessor intrinsics. * Adds one CDE intrinsic __arm_cx1 to test the above changes Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: simon_tatham Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
static __inline__ __attribute__((__clang_arm_builtin_alias(1))) // expected-error {{'__clang_arm_builtin_alias' attribute requires parameter 1 to be an identifier}}
void
integer(void);
[clang] New __attribute__((__clang_arm_mve_alias)). This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
2019-09-02 22:35:09 +08:00
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE Summary: This patch generalizes the existing code to support CDE intrinsics which will share some properties with existing MVE intrinsics (some of the intrinsics will be polymorphic and accept/return values of MVE vector types). Specifically the patch: * Adds new tablegen backends -gen-arm-cde-builtin-def, -gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema, -gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on existing MVE backends. * Renames the '__clang_arm_mve_alias' attribute into '__clang_arm_builtin_alias' (it will be used with CDE intrinsics as well as MVE intrinsics) * Implements semantic checks for the coprocessor argument of the CDE intrinsics as well as the existing coprocessor intrinsics. * Adds one CDE intrinsic __arm_cx1 to test the above changes Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: simon_tatham Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
static __inline__ __attribute__((__clang_arm_builtin_alias(__builtin_arm_nop, 2))) // expected-error {{'__clang_arm_builtin_alias' attribute takes one argument}}
void
twoargs(void);
[clang] New __attribute__((__clang_arm_mve_alias)). This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
2019-09-02 22:35:09 +08:00
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE Summary: This patch generalizes the existing code to support CDE intrinsics which will share some properties with existing MVE intrinsics (some of the intrinsics will be polymorphic and accept/return values of MVE vector types). Specifically the patch: * Adds new tablegen backends -gen-arm-cde-builtin-def, -gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema, -gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on existing MVE backends. * Renames the '__clang_arm_mve_alias' attribute into '__clang_arm_builtin_alias' (it will be used with CDE intrinsics as well as MVE intrinsics) * Implements semantic checks for the coprocessor argument of the CDE intrinsics as well as the existing coprocessor intrinsics. * Adds one CDE intrinsic __arm_cx1 to test the above changes Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: simon_tatham Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
static __attribute__((__clang_arm_builtin_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_builtin_alias' attribute only applies to functions}}
[clang] New __attribute__((__clang_arm_mve_alias)). This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
2019-09-02 22:35:09 +08:00
int variable;