Re: r304201 - [ARM] Fix Neon vector type alignment to 64-bit
On Tue, May 30, 2017 at 3:12 AM, Javed Absar via cfe-commits
wrote:
> Author: javed.absar
> Date: Tue May 30 05:12:15 2017
> New Revision: 304201
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304201&view=rev
> Log:
> [ARM] Fix Neon vector type alignment to 64-bit
>
> The maximum alignment for ARM NEON data types should be 64-bits as specified
> in ARM procedure call standard document Sec. A.2 Notes.
> This patch fixes it from its current larger natural default values, except
> for Android (so as not to break existing ABI).
> Reviewed by: Stephen Hines, Renato Golin.
> Differential Revision: https://reviews.llvm.org/D33205
>
>
> Modified:
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/test/CodeGen/arm-abi-vector.c
> cfe/trunk/test/CodeGen/arm-neon-misc.c
> cfe/trunk/test/CodeGen/arm-swiftcall.c
> cfe/trunk/test/CodeGen/armv7k-abi.c
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=304201&r1=304200&r2=304201&view=diff
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Tue May 30 05:12:15 2017
> @@ -5382,6 +5382,11 @@ public:
> // ARM has atomics up to 8 bytes
> setAtomic();
>
> +if (Triple.getEnvironment() == llvm::Triple::Android)
> + MaxVectorAlign = 128; // don't break existing Android ABI
> +else
> + MaxVectorAlign = 64; // AAPCS
> +
This is an ABI break on darwin as well. There are 40 lines of ifs
*just a few lines above* that pick various ABIs for various targets,
because there are multiple AAPCS variants, and the ARM document
(sadly) isn't gospel.
Is there a way to restrict this to vanilla AAPCS? Maybe sink it into
setABIAAPCS?
> // Do force alignment of members that follow zero length bitfields. If
> // the alignment of the zero-length bitfield is greater than the member
> // that follows it, `bar', `bar' will be aligned as the type of the
>
> Modified: cfe/trunk/test/CodeGen/arm-abi-vector.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-abi-vector.c?rev=304201&r1=304200&r2=304201&view=diff
> ==
> --- cfe/trunk/test/CodeGen/arm-abi-vector.c (original)
> +++ cfe/trunk/test/CodeGen/arm-abi-vector.c Tue May 30 05:12:15 2017
> @@ -133,20 +133,20 @@ double test_5c(__char5 *in) {
>
> double varargs_vec_9c(int fixed, ...) {
> // CHECK: varargs_vec_9c
> -// CHECK: [[VAR:%.*]] = alloca <9 x i8>, align 16
> +// CHECK: [[VAR:%.*]] = alloca <9 x i8>, align 8
> // CHECK: [[ALIGN:%.*]] = and i32 {{%.*}}, -8
> // CHECK: [[AP_ALIGN:%.*]] = inttoptr i32 [[ALIGN]] to i8*
> // CHECK: [[AP_NEXT:%.*]] = getelementptr inbounds i8, i8* [[AP_ALIGN]], i32
> 16
> // CHECK: [[AP_CAST:%.*]] = bitcast i8* [[AP_ALIGN]] to <9 x i8>*
> // CHECK: [[T0:%.*]] = load <9 x i8>, <9 x i8>* [[AP_CAST]], align 8
> -// CHECK: store <9 x i8> [[T0]], <9 x i8>* [[VAR]], align 16
> +// CHECK: store <9 x i8> [[T0]], <9 x i8>* [[VAR]], align 8
> // APCS-GNU: varargs_vec_9c
> -// APCS-GNU: [[VAR:%.*]] = alloca <9 x i8>, align 16
> +// APCS-GNU: [[VAR:%.*]] = alloca <9 x i8>, align 8
> // APCS-GNU: [[AP:%.*]] = load i8*,
> // APCS-GNU: [[AP_NEXT:%.*]] = getelementptr inbounds i8, i8* [[AP]], i32 16
> // APCS-GNU: [[AP_CAST:%.*]] = bitcast i8* [[AP]] to <9 x i8>*
> // APCS-GNU: [[VEC:%.*]] = load <9 x i8>, <9 x i8>* [[AP_CAST]], align 4
> -// APCS-GNU: store <9 x i8> [[VEC]], <9 x i8>* [[VAR]], align 16
> +// APCS-GNU: store <9 x i8> [[VEC]], <9 x i8>* [[VAR]], align 8
> // ANDROID: varargs_vec_9c
> // ANDROID: [[VAR:%.*]] = alloca <9 x i8>, align 16
> // ANDROID: [[ALIGN:%.*]] = and i32 {{%.*}}, -8
> @@ -246,15 +246,15 @@ double test_3s(__short3 *in) {
>
> double varargs_vec_5s(int fixed, ...) {
> // CHECK: varargs_vec_5s
> -// CHECK: [[VAR_ALIGN:%.*]] = alloca <5 x i16>, align 16
> +// CHECK: [[VAR_ALIGN:%.*]] = alloca <5 x i16>, align 8
> // CHECK: [[ALIGN:%.*]] = and i32 {{%.*}}, -8
> // CHECK: [[AP_ALIGN:%.*]] = inttoptr i32 [[ALIGN]] to i8*
> // CHECK: [[AP_NEXT:%.*]] = getelementptr inbounds i8, i8* [[AP_ALIGN]], i32
> 16
> // CHECK: [[AP_CAST:%.*]] = bitcast i8* [[AP_ALIGN]] to <5 x i16>*
> // CHECK: [[VEC:%.*]] = load <5 x i16>, <5 x i16>* [[AP_CAST]], align 8
> -// CHECK: store <5 x i16> [[VEC]], <5 x i16>* [[VAR_ALIGN]], align 16
> +// CHECK: store <5 x i16> [[VEC]], <5 x i16>* [[VAR_ALIGN]], align 8
> // APCS-GNU: varargs_vec_5s
> -// APCS-GNU: [[VAR:%.*]] = alloca <5 x i16>, align 16
> +// APCS-GNU: [[VAR:%.*]] = alloca <5 x i16>, align 8
> // APCS-GNU: [[AP:%.*]] = load i8*,
> // APCS-GNU: [[AP_NEXT:%.*]] = getelementptr inbounds i8, i8* [[AP]], i32 16
> // APCS-GNU: [[AP_CAST:%.*]] = bitcast i8* [[AP]] to <5 x i16>*
>
> Modified: cfe/trunk/test/CodeGen/arm-neon-misc.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-neon
Re: r321301 - [AArch64] Enable fp16 data type for the Builtin for AArch64 only.
On Thu, Dec 21, 2017 at 12:10 PM, Abderrazek Zaafrani via cfe-commits
wrote:
> Author: az
> Date: Thu Dec 21 12:10:03 2017
> New Revision: 321301
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321301&view=rev
> Log:
> [AArch64] Enable fp16 data type for the Builtin for AArch64 only.
>
> Differential Revision: https:://reviews.llvm.org/D41360
>
> Modified:
> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> cfe/trunk/lib/CodeGen/CodeGenFunction.h
> cfe/trunk/test/CodeGen/arm_neon_intrinsics.c
>
> Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=321301&r1=321300&r2=321301&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Thu Dec 21 12:10:03 2017
> @@ -3334,10 +3334,10 @@ static Value *EmitTargetArchBuiltinExpr(
>case llvm::Triple::armeb:
>case llvm::Triple::thumb:
>case llvm::Triple::thumbeb:
> -return CGF->EmitARMBuiltinExpr(BuiltinID, E);
> +return CGF->EmitARMBuiltinExpr(BuiltinID, E, Arch);
>case llvm::Triple::aarch64:
>case llvm::Triple::aarch64_be:
> -return CGF->EmitAArch64BuiltinExpr(BuiltinID, E);
> +return CGF->EmitAArch64BuiltinExpr(BuiltinID, E, Arch);
>case llvm::Triple::x86:
>case llvm::Triple::x86_64:
> return CGF->EmitX86BuiltinExpr(BuiltinID, E);
> @@ -3378,6 +3378,7 @@ Value *CodeGenFunction::EmitTargetBuilti
>
> static llvm::VectorType *GetNeonType(CodeGenFunction *CGF,
> NeonTypeFlags TypeFlags,
> + llvm::Triple::ArchType Arch,
> bool V1Ty=false) {
>int IsQuad = TypeFlags.isQuad();
>switch (TypeFlags.getEltType()) {
> @@ -3388,7 +3389,12 @@ static llvm::VectorType *GetNeonType(Cod
>case NeonTypeFlags::Poly16:
> return llvm::VectorType::get(CGF->Int16Ty, V1Ty ? 1 : (4 << IsQuad));
>case NeonTypeFlags::Float16:
> -return llvm::VectorType::get(CGF->HalfTy, V1Ty ? 1 : (4 << IsQuad));
> +// FIXME: Only AArch64 backend can so far properly handle half types.
> +// Remove else part once ARM backend support for half is complete.
> +if (Arch == llvm::Triple::aarch64)
> + return llvm::VectorType::get(CGF->HalfTy, V1Ty ? 1 : (4 << IsQuad));
> +else
> + return llvm::VectorType::get(CGF->Int16Ty, V1Ty ? 1 : (4 << IsQuad));
Hey Abderrazek,
I don't think you need to pass 'Arch' around. You're already in CGF,
which has a triple:
CGF->getTarget().getTriple().getArch()
It is slightly different from what's passed in EmitTargetArchBuiltinExpr:
CGF->getContext().getAuxTargetInfo()->getTriple().getArch()
though IIRC the 'aux target' is only different for GPU target offloading.
More importantly, should you check for:
LangOpts.HalfArgsAndReturns
and:
LangOpts.NativeHalfType
instead?
I think that mirrors the actual requirement. -fnative-half-type is
disabled by default on ARM. And on AArch64, always picking 'half'
makes -fnative-half-type mandatory. I don't remember the
ramifications off the top of my head, but that seems like a larger
discussion to be had.
Thanks for taking a look!
-Ahmed
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r334550 - [CMake][Darwin] Match cxx-headers -> cxx_headers libcxx target rename.
Author: ab
Date: Tue Jun 12 14:27:36 2018
New Revision: 334550
URL: http://llvm.org/viewvc/llvm-project?rev=334550&view=rev
Log:
[CMake][Darwin] Match cxx-headers -> cxx_headers libcxx target rename.
This was changed in r334477.
Modified:
cfe/trunk/cmake/caches/Apple-stage2.cmake
Modified: cfe/trunk/cmake/caches/Apple-stage2.cmake
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Apple-stage2.cmake?rev=334550&r1=334549&r2=334550&view=diff
==
--- cfe/trunk/cmake/caches/Apple-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Apple-stage2.cmake Tue Jun 12 14:27:36 2018
@@ -61,7 +61,7 @@ set(LLVM_DISTRIBUTION_COMPONENTS
LTO
clang-format
clang-headers
- cxx-headers
+ cxx_headers
${LLVM_TOOLCHAIN_TOOLS}
CACHE STRING "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [libcxx] r334477 - [CMake] Use common variable for all header targets NFC
Hey Petr,
FYI: clang has cmake caches that listed cxx-headers as a dependency;
I fixed that in:
r334550 [CMake][Darwin] Match cxx-headers -> cxx_headers libcxx target rename.
-Ahmed
On Mon, Jun 11, 2018 at 11:58 PM, Petr Hosek via cfe-commits
wrote:
> Author: phosek
> Date: Mon Jun 11 23:58:06 2018
> New Revision: 334477
>
> URL: http://llvm.org/viewvc/llvm-project?rev=334477&view=rev
> Log:
> [CMake] Use common variable for all header targets NFC
>
> This simplifies the handling of header targets.
>
> Modified:
> libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake
> libcxx/trunk/include/CMakeLists.txt
> libcxx/trunk/lib/CMakeLists.txt
>
> Modified: libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake?rev=334477&r1=334476&r2=334477&view=diff
> ==
> --- libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake (original)
> +++ libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake Mon Jun 11 23:58:06 2018
> @@ -78,8 +78,8 @@ macro(setup_abi_lib abidefines abilib ab
>endforeach()
>
>include_directories("${LIBCXX_BINARY_INCLUDE_DIR}")
> - add_custom_target(cxx-abi-headers ALL DEPENDS ${abilib_headers})
> - set(LIBCXX_ABI_HEADERS_TARGET cxx-abi-headers)
> + add_custom_target(cxx_abi_headers ALL DEPENDS ${abilib_headers})
> + set(LIBCXX_CXX_ABI_HEADER_TARGET "cxx_abi_headers")
> endmacro()
>
>
>
> Modified: libcxx/trunk/include/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/CMakeLists.txt?rev=334477&r1=334476&r2=334477&view=diff
> ==
> --- libcxx/trunk/include/CMakeLists.txt (original)
> +++ libcxx/trunk/include/CMakeLists.txt Mon Jun 11 23:58:06 2018
> @@ -228,11 +228,11 @@ if(NOT LIBCXX_USING_INSTALLED_LLVM AND L
> list(APPEND out_files ${dst})
>endif()
>
> - add_custom_target(cxx-headers ALL DEPENDS ${out_files}
> ${LIBCXX_CXX_ABI_LIBRARY_HEADERS})
> + add_custom_target(cxx_headers ALL DEPENDS ${out_files}
> ${LIBCXX_CXX_ABI_HEADER_TARGET})
> else()
> - add_custom_target(cxx-headers)
> + add_custom_target(cxx_headers)
> endif()
> -set_target_properties(cxx-headers PROPERTIES FOLDER "Misc")
> +set_target_properties(cxx_headers PROPERTIES FOLDER "Misc")
>
> if (LIBCXX_INSTALL_HEADERS)
>foreach(file ${files})
>
> Modified: libcxx/trunk/lib/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=334477&r1=334476&r2=334477&view=diff
> ==
> --- libcxx/trunk/lib/CMakeLists.txt (original)
> +++ libcxx/trunk/lib/CMakeLists.txt Mon Jun 11 23:58:06 2018
> @@ -189,8 +189,8 @@ split_list(LIBCXX_LINK_FLAGS)
>
> # Add an object library that contains the compiled source files.
> add_library(cxx_objects OBJECT ${exclude_from_all} ${LIBCXX_SOURCES}
> ${LIBCXX_HEADERS})
> -if(LIBCXX_CXX_ABI_LIBRARY_HEADERS)
> - add_dependencies(cxx_objects ${LIBCXX_CXX_ABI_LIBRARY_HEADERS})
> +if(LIBCXX_CXX_ABI_HEADER_TARGET)
> + add_dependencies(cxx_objects ${LIBCXX_CXX_ABI_HEADER_TARGET})
> endif()
> if(WIN32 AND NOT MINGW)
>target_compile_definitions(cxx_objects
> @@ -286,8 +286,7 @@ if (LIBCXX_ENABLE_STATIC)
> endif()
>
> # Add a meta-target for both libraries.
> -add_custom_target(cxx DEPENDS ${LIBCXX_TARGETS})
> -add_dependencies(cxx cxx-headers ${LIBCXX_ABI_HEADERS_TARGET})
> +add_custom_target(cxx DEPENDS cxx_headers ${LIBCXX_TARGETS})
>
> if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
>file(GLOB LIBCXX_EXPERIMENTAL_SOURCES ../src/experimental/*.cpp)
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [libcxx] r334477 - [CMake] Use common variable for all header targets NFC
Well, that was wrong. There are more install-cxx-headers targets that
the cache distribution implicitly depends on.
Is there a reason for your cxx-headers -> cxx_headers change? If
there is, should the other cxx-headers targets change as well? If
not, can we revert it?
I'll try to reproduce in a local bootstrap build.
-Ahmed
On Tue, Jun 12, 2018 at 2:33 PM, Ahmed Bougacha
wrote:
> Hey Petr,
>
> FYI: clang has cmake caches that listed cxx-headers as a dependency;
> I fixed that in:
> r334550 [CMake][Darwin] Match cxx-headers -> cxx_headers libcxx target rename.
>
> -Ahmed
>
>
> On Mon, Jun 11, 2018 at 11:58 PM, Petr Hosek via cfe-commits
> wrote:
>> Author: phosek
>> Date: Mon Jun 11 23:58:06 2018
>> New Revision: 334477
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=334477&view=rev
>> Log:
>> [CMake] Use common variable for all header targets NFC
>>
>> This simplifies the handling of header targets.
>>
>> Modified:
>> libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake
>> libcxx/trunk/include/CMakeLists.txt
>> libcxx/trunk/lib/CMakeLists.txt
>>
>> Modified: libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake?rev=334477&r1=334476&r2=334477&view=diff
>> ==
>> --- libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake (original)
>> +++ libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake Mon Jun 11 23:58:06 2018
>> @@ -78,8 +78,8 @@ macro(setup_abi_lib abidefines abilib ab
>>endforeach()
>>
>>include_directories("${LIBCXX_BINARY_INCLUDE_DIR}")
>> - add_custom_target(cxx-abi-headers ALL DEPENDS ${abilib_headers})
>> - set(LIBCXX_ABI_HEADERS_TARGET cxx-abi-headers)
>> + add_custom_target(cxx_abi_headers ALL DEPENDS ${abilib_headers})
>> + set(LIBCXX_CXX_ABI_HEADER_TARGET "cxx_abi_headers")
>> endmacro()
>>
>>
>>
>> Modified: libcxx/trunk/include/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/CMakeLists.txt?rev=334477&r1=334476&r2=334477&view=diff
>> ==
>> --- libcxx/trunk/include/CMakeLists.txt (original)
>> +++ libcxx/trunk/include/CMakeLists.txt Mon Jun 11 23:58:06 2018
>> @@ -228,11 +228,11 @@ if(NOT LIBCXX_USING_INSTALLED_LLVM AND L
>> list(APPEND out_files ${dst})
>>endif()
>>
>> - add_custom_target(cxx-headers ALL DEPENDS ${out_files}
>> ${LIBCXX_CXX_ABI_LIBRARY_HEADERS})
>> + add_custom_target(cxx_headers ALL DEPENDS ${out_files}
>> ${LIBCXX_CXX_ABI_HEADER_TARGET})
>> else()
>> - add_custom_target(cxx-headers)
>> + add_custom_target(cxx_headers)
>> endif()
>> -set_target_properties(cxx-headers PROPERTIES FOLDER "Misc")
>> +set_target_properties(cxx_headers PROPERTIES FOLDER "Misc")
>>
>> if (LIBCXX_INSTALL_HEADERS)
>>foreach(file ${files})
>>
>> Modified: libcxx/trunk/lib/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=334477&r1=334476&r2=334477&view=diff
>> ==
>> --- libcxx/trunk/lib/CMakeLists.txt (original)
>> +++ libcxx/trunk/lib/CMakeLists.txt Mon Jun 11 23:58:06 2018
>> @@ -189,8 +189,8 @@ split_list(LIBCXX_LINK_FLAGS)
>>
>> # Add an object library that contains the compiled source files.
>> add_library(cxx_objects OBJECT ${exclude_from_all} ${LIBCXX_SOURCES}
>> ${LIBCXX_HEADERS})
>> -if(LIBCXX_CXX_ABI_LIBRARY_HEADERS)
>> - add_dependencies(cxx_objects ${LIBCXX_CXX_ABI_LIBRARY_HEADERS})
>> +if(LIBCXX_CXX_ABI_HEADER_TARGET)
>> + add_dependencies(cxx_objects ${LIBCXX_CXX_ABI_HEADER_TARGET})
>> endif()
>> if(WIN32 AND NOT MINGW)
>>target_compile_definitions(cxx_objects
>> @@ -286,8 +286,7 @@ if (LIBCXX_ENABLE_STATIC)
>> endif()
>>
>> # Add a meta-target for both libraries.
>> -add_custom_target(cxx DEPENDS ${LIBCXX_TARGETS})
>> -add_dependencies(cxx cxx-headers ${LIBCXX_ABI_HEADERS_TARGET})
>> +add_custom_target(cxx DEPENDS cxx_headers ${LIBCXX_TARGETS})
>>
>> if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
>>file(GLOB LIBCXX_EXPERIMENTAL_SOURCES ../src/experimental/*.cpp)
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r354538 - [AArch64] Change size suffix for FP16FML intrinsics.
Author: ab
Date: Wed Feb 20 17:13:27 2019
New Revision: 354538
URL: http://llvm.org/viewvc/llvm-project?rev=354538&view=rev
Log:
[AArch64] Change size suffix for FP16FML intrinsics.
These currently use _u32, but they should instead use _f16, the
types of the multiplication (matching the various integer vmlal
variants).
Differential Revision: https://reviews.llvm.org/D58306
Modified:
cfe/trunk/include/clang/Basic/arm_neon.td
cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c
Modified: cfe/trunk/include/clang/Basic/arm_neon.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/arm_neon.td?rev=354538&r1=354537&r2=354538&view=diff
==
--- cfe/trunk/include/clang/Basic/arm_neon.td (original)
+++ cfe/trunk/include/clang/Basic/arm_neon.td Wed Feb 20 17:13:27 2019
@@ -1651,18 +1651,18 @@ let ArchGuard = "defined(__ARM_FEATURE_D
// v8.2-A FP16 fused multiply-add long instructions.
let ArchGuard = "defined(__ARM_FEATURE_FP16FML) && defined(__aarch64__)" in {
- def VFMLAL_LOW : SInst<"vfmlal_low", "ffHH", "UiQUi">;
- def VFMLSL_LOW : SInst<"vfmlsl_low", "ffHH", "UiQUi">;
- def VFMLAL_HIGH : SInst<"vfmlal_high", "ffHH", "UiQUi">;
- def VFMLSL_HIGH : SInst<"vfmlsl_high", "ffHH", "UiQUi">;
+ def VFMLAL_LOW : SInst<"vfmlal_low", "ffHH", "hQh">;
+ def VFMLSL_LOW : SInst<"vfmlsl_low", "ffHH", "hQh">;
+ def VFMLAL_HIGH : SInst<"vfmlal_high", "ffHH", "hQh">;
+ def VFMLSL_HIGH : SInst<"vfmlsl_high", "ffHH", "hQh">;
- def VFMLAL_LANE_LOW : SOpInst<"vfmlal_lane_low", "ffH0i", "UiQUi",
OP_FMLAL_LN>;
- def VFMLSL_LANE_LOW : SOpInst<"vfmlsl_lane_low", "ffH0i", "UiQUi",
OP_FMLSL_LN>;
- def VFMLAL_LANE_HIGH : SOpInst<"vfmlal_lane_high", "ffH0i", "UiQUi",
OP_FMLAL_LN_Hi>;
- def VFMLSL_LANE_HIGH : SOpInst<"vfmlsl_lane_high", "ffH0i", "UiQUi",
OP_FMLSL_LN_Hi>;
+ def VFMLAL_LANE_LOW : SOpInst<"vfmlal_lane_low", "ffH0i", "hQh",
OP_FMLAL_LN>;
+ def VFMLSL_LANE_LOW : SOpInst<"vfmlsl_lane_low", "ffH0i", "hQh",
OP_FMLSL_LN>;
+ def VFMLAL_LANE_HIGH : SOpInst<"vfmlal_lane_high", "ffH0i", "hQh",
OP_FMLAL_LN_Hi>;
+ def VFMLSL_LANE_HIGH : SOpInst<"vfmlsl_lane_high", "ffH0i", "hQh",
OP_FMLSL_LN_Hi>;
- def VFMLAL_LANEQ_LOW : SOpInst<"vfmlal_laneq_low", "ffH1i", "UiQUi",
OP_FMLAL_LN>;
- def VFMLSL_LANEQ_LOW : SOpInst<"vfmlsl_laneq_low", "ffH1i", "UiQUi",
OP_FMLSL_LN>;
- def VFMLAL_LANEQ_HIGH : SOpInst<"vfmlal_laneq_high", "ffH1i", "UiQUi",
OP_FMLAL_LN_Hi>;
- def VFMLSL_LANEQ_HIGH : SOpInst<"vfmlsl_laneq_high", "ffH1i", "UiQUi",
OP_FMLSL_LN_Hi>;
+ def VFMLAL_LANEQ_LOW : SOpInst<"vfmlal_laneq_low", "ffH1i", "hQh",
OP_FMLAL_LN>;
+ def VFMLSL_LANEQ_LOW : SOpInst<"vfmlsl_laneq_low", "ffH1i", "hQh",
OP_FMLSL_LN>;
+ def VFMLAL_LANEQ_HIGH : SOpInst<"vfmlal_laneq_high", "ffH1i", "hQh",
OP_FMLAL_LN_Hi>;
+ def VFMLSL_LANEQ_HIGH : SOpInst<"vfmlsl_laneq_high", "ffH1i", "hQh",
OP_FMLSL_LN_Hi>;
}
Modified: cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c?rev=354538&r1=354537&r2=354538&view=diff
==
--- cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c (original)
+++ cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c Wed Feb 20 17:13:27 2019
@@ -9,188 +9,188 @@
// Vector form
-float32x2_t test_vfmlal_low_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlal_low_u32(<2 x float> %a, <4 x
half> %b, <4 x half> %c)
+float32x2_t test_vfmlal_low_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlal_low_f16(<2 x float> %a, <4 x
half> %b, <4 x half> %c)
// CHECK: [[RESULT:%.*]] = call <2 x float>
@llvm.aarch64.neon.fmlal.v2f32.v4f16(<2 x float> %a, <4 x half> %b, <4 x half>
%c)
// CHECK: ret <2 x float> [[RESULT]]
- return vfmlal_low_u32(a, b, c);
+ return vfmlal_low_f16(a, b, c);
}
-float32x2_t test_vfmlsl_low_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlsl_low_u32(<2 x float> %a, <4 x
half> %b, <4 x half> %c)
+float32x2_t test_vfmlsl_low_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlsl_low_f16(<2 x float> %a, <4 x
half> %b, <4 x half> %c)
// CHECK: [[RESULT:%.*]] = call <2 x float>
@llvm.aarch64.neon.fmlsl.v2f32.v4f16(<2 x float> %a, <4 x half> %b, <4 x half>
%c)
// CHECK: ret <2 x float> [[RESULT]]
- return vfmlsl_low_u32(a, b, c);
+ return vfmlsl_low_f16(a, b, c);
}
-float32x2_t test_vfmlal_high_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlal_high_u32(<2 x float> %a, <4 x
half> %b, <4 x half> %c)
+float32x2_t test_vfmlal_high_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlal_high_f16(<2 x float> %a, <4 x
half> %b, <4 x half> %c)
//
Re: [libcxx] r334477 - [CMake] Use common variable for all header targets NFC
On Tue, Jun 12, 2018 at 8:04 PM, Ahmed Bougacha
wrote:
> Well, that was wrong. There are more install-cxx-headers targets that
> the cache distribution implicitly depends on.
>
> Is there a reason for your cxx-headers -> cxx_headers change? If
> there is, should the other cxx-headers targets change as well? If
> not, can we revert it?
To circle back to this: these two changes seem to have stabilized the situation:
https://reviews.llvm.org/D48700
https://reviews.llvm.org/D48701
-Ahmed
> I'll try to reproduce in a local bootstrap build.
>
> -Ahmed
>
>
> On Tue, Jun 12, 2018 at 2:33 PM, Ahmed Bougacha
> wrote:
>> Hey Petr,
>>
>> FYI: clang has cmake caches that listed cxx-headers as a dependency;
>> I fixed that in:
>> r334550 [CMake][Darwin] Match cxx-headers -> cxx_headers libcxx target
>> rename.
>>
>> -Ahmed
>>
>>
>> On Mon, Jun 11, 2018 at 11:58 PM, Petr Hosek via cfe-commits
>> wrote:
>>> Author: phosek
>>> Date: Mon Jun 11 23:58:06 2018
>>> New Revision: 334477
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=334477&view=rev
>>> Log:
>>> [CMake] Use common variable for all header targets NFC
>>>
>>> This simplifies the handling of header targets.
>>>
>>> Modified:
>>> libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake
>>> libcxx/trunk/include/CMakeLists.txt
>>> libcxx/trunk/lib/CMakeLists.txt
>>>
>>> Modified: libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake?rev=334477&r1=334476&r2=334477&view=diff
>>> ==
>>> --- libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake (original)
>>> +++ libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake Mon Jun 11 23:58:06
>>> 2018
>>> @@ -78,8 +78,8 @@ macro(setup_abi_lib abidefines abilib ab
>>>endforeach()
>>>
>>>include_directories("${LIBCXX_BINARY_INCLUDE_DIR}")
>>> - add_custom_target(cxx-abi-headers ALL DEPENDS ${abilib_headers})
>>> - set(LIBCXX_ABI_HEADERS_TARGET cxx-abi-headers)
>>> + add_custom_target(cxx_abi_headers ALL DEPENDS ${abilib_headers})
>>> + set(LIBCXX_CXX_ABI_HEADER_TARGET "cxx_abi_headers")
>>> endmacro()
>>>
>>>
>>>
>>> Modified: libcxx/trunk/include/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/CMakeLists.txt?rev=334477&r1=334476&r2=334477&view=diff
>>> ==
>>> --- libcxx/trunk/include/CMakeLists.txt (original)
>>> +++ libcxx/trunk/include/CMakeLists.txt Mon Jun 11 23:58:06 2018
>>> @@ -228,11 +228,11 @@ if(NOT LIBCXX_USING_INSTALLED_LLVM AND L
>>> list(APPEND out_files ${dst})
>>>endif()
>>>
>>> - add_custom_target(cxx-headers ALL DEPENDS ${out_files}
>>> ${LIBCXX_CXX_ABI_LIBRARY_HEADERS})
>>> + add_custom_target(cxx_headers ALL DEPENDS ${out_files}
>>> ${LIBCXX_CXX_ABI_HEADER_TARGET})
>>> else()
>>> - add_custom_target(cxx-headers)
>>> + add_custom_target(cxx_headers)
>>> endif()
>>> -set_target_properties(cxx-headers PROPERTIES FOLDER "Misc")
>>> +set_target_properties(cxx_headers PROPERTIES FOLDER "Misc")
>>>
>>> if (LIBCXX_INSTALL_HEADERS)
>>>foreach(file ${files})
>>>
>>> Modified: libcxx/trunk/lib/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=334477&r1=334476&r2=334477&view=diff
>>> ==
>>> --- libcxx/trunk/lib/CMakeLists.txt (original)
>>> +++ libcxx/trunk/lib/CMakeLists.txt Mon Jun 11 23:58:06 2018
>>> @@ -189,8 +189,8 @@ split_list(LIBCXX_LINK_FLAGS)
>>>
>>> # Add an object library that contains the compiled source files.
>>> add_library(cxx_objects OBJECT ${exclude_from_all} ${LIBCXX_SOURCES}
>>> ${LIBCXX_HEADERS})
>>> -if(LIBCXX_CXX_ABI_LIBRARY_HEADERS)
>>> - add_dependencies(cxx_objects ${LIBCXX_CXX_ABI_LIBRARY_HEADERS})
>>> +if(LIBCXX_CXX_ABI_HEADER_TARGET)
>>> + add_dependencies(cxx_objects ${LIBCXX_CXX_ABI_HEADER_TARGET})
>>> endif()
>>> if(WIN32 AND NOT MINGW)
>>>target_compile_definitions(cxx_objects
>>> @@ -286,8 +286,7 @@ if (LIBCXX_ENABLE_STATIC)
>>> endif()
>>>
>>> # Add a meta-target for both libraries.
>>> -add_custom_target(cxx DEPENDS ${LIBCXX_TARGETS})
>>> -add_dependencies(cxx cxx-headers ${LIBCXX_ABI_HEADERS_TARGET})
>>> +add_custom_target(cxx DEPENDS cxx_headers ${LIBCXX_TARGETS})
>>>
>>> if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
>>>file(GLOB LIBCXX_EXPERIMENTAL_SOURCES ../src/experimental/*.cpp)
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335898 - [CMake] Make bootstrap and compiler-rt depend on cxx-headers.
Author: ab
Date: Thu Jun 28 11:35:25 2018
New Revision: 335898
URL: http://llvm.org/viewvc/llvm-project?rev=335898&view=rev
Log:
[CMake] Make bootstrap and compiler-rt depend on cxx-headers.
Since r334468, we no longer always copy the libcxx headers by virtue of
their presence when cmake runs.
This makes some of the later stages (compiler-rt, and the bootstrapped
stages) depend on them being copied, via the cxx-headers target.
Differential Revision: https://reviews.llvm.org/D48700
Modified:
cfe/trunk/CMakeLists.txt
cfe/trunk/runtime/CMakeLists.txt
Modified: cfe/trunk/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=335898&r1=335897&r2=335898&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Thu Jun 28 11:35:25 2018
@@ -621,10 +621,15 @@ if (CLANG_ENABLE_BOOTSTRAP)
LLVM_ENABLE_PROJECTS
LLVM_ENABLE_RUNTIMES)
- # We don't need to depend on compiler-rt if we're building instrumented
+ # We don't need to depend on compiler-rt/libcxx if we're building
instrumented
# because the next stage will use the same compiler used to build this stage.
- if(TARGET compiler-rt AND NOT LLVM_BUILD_INSTRUMENTED)
-add_dependencies(clang-bootstrap-deps compiler-rt)
+ if(NOT LLVM_BUILD_INSTRUMENTED)
+if(TARGET compiler-rt)
+ add_dependencies(clang-bootstrap-deps compiler-rt)
+endif()
+if(TARGET cxx-headers)
+ add_dependencies(clang-bootstrap-deps cxx-headers)
+endif()
endif()
set(C_COMPILER "clang")
Modified: cfe/trunk/runtime/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=335898&r1=335897&r2=335898&view=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Thu Jun 28 11:35:25 2018
@@ -58,8 +58,12 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
endif()
endforeach()
+ if(TARGET cxx-headers)
+set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+ endif()
+
ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang
+DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
PREFIX ${COMPILER_RT_PREFIX}
SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
STAMP_DIR ${STAMP_DIR}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r335899 - [CMake] Rename cxx_headers back to cxx-headers.
Author: ab
Date: Thu Jun 28 11:35:35 2018
New Revision: 335899
URL: http://llvm.org/viewvc/llvm-project?rev=335899&view=rev
Log:
[CMake] Rename cxx_headers back to cxx-headers.
r334477 renamed the cxx-headers target to cxx_headers, but various
pieces sort-of expect the target names to match the component (e.g.,
LLVM_DISTRIBUTION_COMPONENTS in the various bootstrap caches, which, via
some magic foreign to me, seems to expect cxx-headers,
install-cxx-headers, and install-cxx-headers-stripped to exist.)
Revert back to cxx-headers.
Differential Revision: https://reviews.llvm.org/D48701
Modified:
libcxx/trunk/include/CMakeLists.txt
libcxx/trunk/lib/CMakeLists.txt
Modified: libcxx/trunk/include/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/CMakeLists.txt?rev=335899&r1=335898&r2=335899&view=diff
==
--- libcxx/trunk/include/CMakeLists.txt (original)
+++ libcxx/trunk/include/CMakeLists.txt Thu Jun 28 11:35:35 2018
@@ -228,11 +228,11 @@ if(NOT LIBCXX_USING_INSTALLED_LLVM AND L
list(APPEND out_files ${dst})
endif()
- add_custom_target(cxx_headers ALL DEPENDS ${out_files}
${LIBCXX_CXX_ABI_HEADER_TARGET})
+ add_custom_target(cxx-headers ALL DEPENDS ${out_files}
${LIBCXX_CXX_ABI_HEADER_TARGET})
else()
- add_custom_target(cxx_headers)
+ add_custom_target(cxx-headers)
endif()
-set_target_properties(cxx_headers PROPERTIES FOLDER "Misc")
+set_target_properties(cxx-headers PROPERTIES FOLDER "Misc")
if (LIBCXX_INSTALL_HEADERS)
foreach(file ${files})
@@ -255,7 +255,7 @@ if (LIBCXX_INSTALL_HEADERS)
if (NOT CMAKE_CONFIGURATION_TYPES)
add_custom_target(install-cxx-headers
- DEPENDS cxx_headers ${generated_config_deps}
+ DEPENDS cxx-headers ${generated_config_deps}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=cxx-headers
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
Modified: libcxx/trunk/lib/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=335899&r1=335898&r2=335899&view=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Thu Jun 28 11:35:35 2018
@@ -286,7 +286,7 @@ if (LIBCXX_ENABLE_STATIC)
endif()
# Add a meta-target for both libraries.
-add_custom_target(cxx DEPENDS cxx_headers ${LIBCXX_TARGETS})
+add_custom_target(cxx DEPENDS cxx-headers ${LIBCXX_TARGETS})
if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
file(GLOB LIBCXX_EXPERIMENTAL_SOURCES ../src/experimental/*.cpp)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r319727 - Generalize "static data member instantiated" notification to cover variable templates too.
On Tue, Dec 5, 2017 at 11:40 AM, Richard Smith via cfe-commits
wrote:
> Sorry about that, fixed in r319817.
Hey Richard,
Looks like that's not enough on darwin:
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/44764/consoleFull#-126347322349ba4694-19c4-4d7e-bec5-911270d8a58c
Can you have a look? Thanks!
-Ahmed
> On 5 December 2017 at 10:38, Galina Kistanova via cfe-commits
> wrote:
>>
>> Hello Richard,
>>
>> This commit broke tests on one of our bots:
>>
>>
>> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6568
>>
>> Failing Tests (3):
>> . . .
>> Clang :: Modules/var-templates.cpp
>> . . .
>>
>> Please have a look?
>>
>> Thanks
>>
>> Galina
>>
>> On Mon, Dec 4, 2017 at 5:31 PM, Richard Smith via cfe-commits
>> wrote:
>>>
>>> Author: rsmith
>>> Date: Mon Dec 4 17:31:47 2017
>>> New Revision: 319727
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=319727&view=rev
>>> Log:
>>> Generalize "static data member instantiated" notification to cover
>>> variable templates too.
>>>
>>> While here, split the "point of instantiation changed" notification out
>>> from
>>> it; these two really are orthogonal changes.
>>>
>>> Added:
>>> cfe/trunk/test/Modules/var-templates.cpp
>>> Modified:
>>> cfe/trunk/include/clang/AST/ASTMutationListener.h
>>> cfe/trunk/include/clang/Sema/Sema.h
>>> cfe/trunk/include/clang/Serialization/ASTWriter.h
>>> cfe/trunk/lib/AST/Decl.cpp
>>> cfe/trunk/lib/Frontend/MultiplexConsumer.cpp
>>> cfe/trunk/lib/Sema/SemaExpr.cpp
>>> cfe/trunk/lib/Sema/SemaTemplate.cpp
>>> cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
>>> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
>>> cfe/trunk/lib/Sema/SemaType.cpp
>>> cfe/trunk/lib/Serialization/ASTCommon.h
>>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>>> cfe/trunk/lib/Serialization/ASTWriter.cpp
>>>
>>> Modified: cfe/trunk/include/clang/AST/ASTMutationListener.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTMutationListener.h?rev=319727&r1=319726&r2=319727&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/AST/ASTMutationListener.h (original)
>>> +++ cfe/trunk/include/clang/AST/ASTMutationListener.h Mon Dec 4 17:31:47
>>> 2017
>>> @@ -36,6 +36,7 @@ namespace clang {
>>>class QualType;
>>>class RecordDecl;
>>>class TagDecl;
>>> + class ValueDecl;
>>>class VarDecl;
>>>class VarTemplateDecl;
>>>class VarTemplateSpecializationDecl;
>>> @@ -87,8 +88,13 @@ public:
>>>/// \brief An implicit member got a definition.
>>>virtual void CompletedImplicitDefinition(const FunctionDecl *D) {}
>>>
>>> - /// \brief A static data member was implicitly instantiated.
>>> - virtual void StaticDataMemberInstantiated(const VarDecl *D) {}
>>> + /// \brief The instantiation of a templated function or variable was
>>> + /// requested. In particular, the point of instantiation and template
>>> + /// specialization kind of \p D may have changed.
>>> + virtual void InstantiationRequested(const ValueDecl *D) {}
>>> +
>>> + /// \brief A templated variable's definition was implicitly
>>> instantiated.
>>> + virtual void VariableDefinitionInstantiated(const VarDecl *D) {}
>>>
>>>/// \brief A function template's definition was instantiated.
>>>virtual void FunctionDefinitionInstantiated(const FunctionDecl *D) {}
>>>
>>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=319727&r1=319726&r2=319727&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>>> +++ cfe/trunk/include/clang/Sema/Sema.h Mon Dec 4 17:31:47 2017
>>> @@ -7790,11 +7790,6 @@ public:
>>> VarDecl *Var, bool Recursive =
>>> false,
>>> bool DefinitionRequired = false,
>>> bool AtEndOfTU = false);
>>> - void InstantiateStaticDataMemberDefinition(
>>> - SourceLocation
>>> PointOfInstantiation,
>>> - VarDecl *Var,
>>> - bool Recursive = false,
>>> - bool DefinitionRequired = false);
>>>
>>>void InstantiateMemInitializers(CXXConstructorDecl *New,
>>>const CXXConstructorDecl *Tmpl,
>>>
>>> Modified: cfe/trunk/include/clang/Serialization/ASTWriter.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTWriter.h?rev=319727&r1=319726&r2=319727&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Serialization/ASTWriter.h (original)
>>> +++ cfe/trunk/include/cla
r320112 - Remove line-endings added by r320089. NFC.
Author: ab Date: Thu Dec 7 14:58:02 2017 New Revision: 320112 URL: http://llvm.org/viewvc/llvm-project?rev=320112&view=rev Log: Remove line-endings added by r320089. NFC. Modified: cfe/trunk/include/clang/Basic/LangOptions.def Modified: cfe/trunk/include/clang/Basic/LangOptions.def URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=320112&r1=320111&r2=320112&view=diff == --- cfe/trunk/include/clang/Basic/LangOptions.def (original) +++ cfe/trunk/include/clang/Basic/LangOptions.def Thu Dec 7 14:58:02 2017 @@ -1,188 +1,188 @@ -//===--- LangOptions.def - Language option database -*- C++ -*-===// -// -// The LLVM Compiler Infrastructure -// -// This file is distributed under the University of Illinois Open Source -// License. See LICENSE.TXT for details. -// -//===--===// -// -// This file defines the language options. Users of this file must -// define the LANGOPT macro to make use of this information. -// -// Optionally, the user may also define: -// -// BENIGN_LANGOPT: for options that don't affect the construction of the AST in -// any way (that is, the value can be different between an implicit module -// and the user of that module). -// -// COMPATIBLE_LANGOPT: for options that affect the construction of the AST in -// a way that doesn't prevent interoperability (that is, the value can be -// different between an explicit module and the user of that module). -// -// ENUM_LANGOPT: for options that have enumeration, rather than unsigned, type. -// -// VALUE_LANGOPT: for options that describe a value rather than a flag. -// -// BENIGN_ENUM_LANGOPT, COMPATIBLE_ENUM_LANGOPT, -// BENIGN_VALUE_LANGOPT, COMPATIBLE_VALUE_LANGOPT: combinations of the above. -// -// FIXME: Clients should be able to more easily select whether they want -// different levels of compatibility versus how to handle different kinds -// of option. -// -// The Description field should be a noun phrase, for instance "frobbing all -// widgets" or "C's implicit blintz feature". -//===--===// - -#ifndef LANGOPT -# error Define the LANGOPT macro to handle language options -#endif - -#ifndef COMPATIBLE_LANGOPT -# define COMPATIBLE_LANGOPT(Name, Bits, Default, Description) \ - LANGOPT(Name, Bits, Default, Description) -#endif - -#ifndef BENIGN_LANGOPT -# define BENIGN_LANGOPT(Name, Bits, Default, Description) \ - COMPATIBLE_LANGOPT(Name, Bits, Default, Description) -#endif - -#ifndef ENUM_LANGOPT -# define ENUM_LANGOPT(Name, Type, Bits, Default, Description) \ - LANGOPT(Name, Bits, Default, Description) -#endif - -#ifndef COMPATIBLE_ENUM_LANGOPT -# define COMPATIBLE_ENUM_LANGOPT(Name, Type, Bits, Default, Description) \ - ENUM_LANGOPT(Name, Type, Bits, Default, Description) -#endif - -#ifndef BENIGN_ENUM_LANGOPT -# define BENIGN_ENUM_LANGOPT(Name, Type, Bits, Default, Description) \ - COMPATIBLE_ENUM_LANGOPT(Name, Type, Bits, Default, Description) -#endif - -#ifndef VALUE_LANGOPT -# define VALUE_LANGOPT(Name, Bits, Default, Description) \ - LANGOPT(Name, Bits, Default, Description) -#endif - -#ifndef COMPATIBLE_VALUE_LANGOPT -# define COMPATIBLE_VALUE_LANGOPT(Name, Bits, Default, Description) \ - VALUE_LANGOPT(Name, Bits, Default, Description) -#endif - -#ifndef BENIGN_VALUE_LANGOPT -# define BENIGN_VALUE_LANGOPT(Name, Bits, Default, Description) \ - COMPATIBLE_VALUE_LANGOPT(Name, Bits, Default, Description) -#endif - -// FIXME: A lot of the BENIGN_ options should be COMPATIBLE_ instead. -LANGOPT(C99 , 1, 0, "C99") -LANGOPT(C11 , 1, 0, "C11") -LANGOPT(C17 , 1, 0, "C17") -LANGOPT(MSVCCompat, 1, 0, "Microsoft Visual C++ full compatibility mode") -LANGOPT(MicrosoftExt , 1, 0, "Microsoft C++ extensions") -LANGOPT(AsmBlocks , 1, 0, "Microsoft inline asm blocks") -LANGOPT(Borland , 1, 0, "Borland extensions") -LANGOPT(CPlusPlus , 1, 0, "C++") -LANGOPT(CPlusPlus11 , 1, 0, "C++11") -LANGOPT(CPlusPlus14 , 1, 0, "C++14") -LANGOPT(CPlusPlus17 , 1, 0, "C++17") -LANGOPT(CPlusPlus2a , 1, 0, "C++2a") -LANGOPT(ObjC1 , 1, 0, "Objective-C 1") -LANGOPT(ObjC2 , 1, 0, "Objective-C 2") -BENIGN_LANGOPT(ObjCDefaultSynthProperties , 1, 0, - "Objective-C auto-synthesized properties") -BENIGN_LANGOPT(EncodeExtendedBlockSig , 1, 0, - "Encoding extended block type signature") -BENIGN_LANGOPT(ObjCInferRelatedResultType , 1, 1, - "Objective-C related result type inference") -LANGOPT(AppExt , 1, 0, "Objective-C App Extension") -LANGOPT(Trigraphs , 1, 0,"trigraphs") -LANGOPT(LineComment , 1, 0, "'//' comments") -LANGOPT(Bool , 1, 0, "bool,
Re: r320089 - Add new language mode flags for C17.
On Thu, Dec 7, 2017 at 2:56 PM, Richard Smith via cfe-commits wrote: > Looks like this might have messed up the line endings in a few files? Should be taken care of in r320112. -Ahmed > On 7 December 2017 at 13:46, Aaron Ballman via cfe-commits > wrote: >> >> Author: aaronballman >> Date: Thu Dec 7 13:46:26 2017 >> New Revision: 320089 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=320089&view=rev >> Log: >> Add new language mode flags for C17. >> >> This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode >> flags for C17 and updates the value of __STDC_VERSION__ to the value based >> on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is >> expected that we (and GCC) will add c18 flags as aliases once the ballot >> passes. >> >> Modified: >> cfe/trunk/docs/ReleaseNotes.rst >> cfe/trunk/include/clang/Basic/LangOptions.def >> cfe/trunk/include/clang/Frontend/LangStandard.h >> cfe/trunk/include/clang/Frontend/LangStandards.def >> cfe/trunk/lib/Frontend/CompilerInvocation.cpp >> cfe/trunk/lib/Frontend/InitPreprocessor.cpp >> cfe/trunk/test/Driver/unknown-std.c >> >> Modified: cfe/trunk/docs/ReleaseNotes.rst >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=320089&r1=320088&r2=320089&view=diff >> >> == >> --- cfe/trunk/docs/ReleaseNotes.rst (original) >> +++ cfe/trunk/docs/ReleaseNotes.rst Thu Dec 7 13:46:26 2017 >> @@ -121,6 +121,12 @@ New Compiler Flags >>number of attributes are supported outside of C++ mode. See the Clang >>attribute documentation for more information about which attributes are >>supported for each syntax. >> + >> +- Added the ``-std=c17``, ``-std=gnu17``, and ``-std=iso9899:2017`` >> language >> + mode flags for compatibility with GCC. This enables support for the >> next >> + version of the C standard, expected to be published by ISO in 2018. The >> only >> + difference between the ``-std=c17`` and ``-std=c11`` language modes is >> the >> + value of the ``__STDC_VERSION__`` macro, as C17 is a bug fix release. >> >> Deprecated Compiler Flags >> - >> >> Modified: cfe/trunk/include/clang/Basic/LangOptions.def >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=320089&r1=320088&r2=320089&view=diff >> >> == >> --- cfe/trunk/include/clang/Basic/LangOptions.def (original) >> +++ cfe/trunk/include/clang/Basic/LangOptions.def Thu Dec 7 13:46:26 2017 >> @@ -1,187 +1,188 @@ >> -//===--- LangOptions.def - Language option database -*- C++ >> -*-===// >> -// >> -// The LLVM Compiler Infrastructure >> -// >> -// This file is distributed under the University of Illinois Open Source >> -// License. See LICENSE.TXT for details. >> -// >> >> -//===--===// >> -// >> -// This file defines the language options. Users of this file must >> -// define the LANGOPT macro to make use of this information. >> -// >> -// Optionally, the user may also define: >> -// >> -// BENIGN_LANGOPT: for options that don't affect the construction of the >> AST in >> -// any way (that is, the value can be different between an implicit >> module >> -// and the user of that module). >> -// >> -// COMPATIBLE_LANGOPT: for options that affect the construction of the >> AST in >> -// a way that doesn't prevent interoperability (that is, the value >> can be >> -// different between an explicit module and the user of that module). >> -// >> -// ENUM_LANGOPT: for options that have enumeration, rather than unsigned, >> type. >> -// >> -// VALUE_LANGOPT: for options that describe a value rather than a flag. >> -// >> -// BENIGN_ENUM_LANGOPT, COMPATIBLE_ENUM_LANGOPT, >> -// BENIGN_VALUE_LANGOPT, COMPATIBLE_VALUE_LANGOPT: combinations of the >> above. >> -// >> -// FIXME: Clients should be able to more easily select whether they want >> -// different levels of compatibility versus how to handle different kinds >> -// of option. >> -// >> -// The Description field should be a noun phrase, for instance "frobbing >> all >> -// widgets" or "C's implicit blintz feature". >> >> -//===--===// >> - >> -#ifndef LANGOPT >> -# error Define the LANGOPT macro to handle language options >> -#endif >> - >> -#ifndef COMPATIBLE_LANGOPT >> -# define COMPATIBLE_LANGOPT(Name, Bits, Default, Description) \ >> - LANGOPT(Name, Bits, Default, Description) >> -#endif >> - >> -#ifndef BENIGN_LANGOPT >> -# define BENIGN_LANGOPT(Name, Bits, Default, Description) \ >> - COMPATIBLE_LANGOPT(Name, Bits, Default, Description) >> -#endif >> - >> -#ifndef ENUM_LANGOPT >> -# define ENUM_LANGOPT(Name, Type, Bits, Default, Description) \ >> - LANG
Re: r320089 - Add new language mode flags for C17.
On Thu, Dec 7, 2017 at 3:00 PM, Aaron Ballman wrote: > On Thu, Dec 7, 2017 at 5:59 PM, Ahmed Bougacha > wrote: >> On Thu, Dec 7, 2017 at 2:56 PM, Richard Smith via cfe-commits >> wrote: >>> Looks like this might have messed up the line endings in a few files? >> >> Should be taken care of in r320112. Oh, I missed some files. I'll take care of it. -Ahmed > Thanks, I was just getting on that. Sorry about the inadvertent churn there! > > ~Aaron > >> >> -Ahmed >> >>> On 7 December 2017 at 13:46, Aaron Ballman via cfe-commits >>> wrote: Author: aaronballman Date: Thu Dec 7 13:46:26 2017 New Revision: 320089 URL: http://llvm.org/viewvc/llvm-project?rev=320089&view=rev Log: Add new language mode flags for C17. This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode flags for C17 and updates the value of __STDC_VERSION__ to the value based on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is expected that we (and GCC) will add c18 flags as aliases once the ballot passes. Modified: cfe/trunk/docs/ReleaseNotes.rst cfe/trunk/include/clang/Basic/LangOptions.def cfe/trunk/include/clang/Frontend/LangStandard.h cfe/trunk/include/clang/Frontend/LangStandards.def cfe/trunk/lib/Frontend/CompilerInvocation.cpp cfe/trunk/lib/Frontend/InitPreprocessor.cpp cfe/trunk/test/Driver/unknown-std.c Modified: cfe/trunk/docs/ReleaseNotes.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=320089&r1=320088&r2=320089&view=diff == --- cfe/trunk/docs/ReleaseNotes.rst (original) +++ cfe/trunk/docs/ReleaseNotes.rst Thu Dec 7 13:46:26 2017 @@ -121,6 +121,12 @@ New Compiler Flags number of attributes are supported outside of C++ mode. See the Clang attribute documentation for more information about which attributes are supported for each syntax. + +- Added the ``-std=c17``, ``-std=gnu17``, and ``-std=iso9899:2017`` language + mode flags for compatibility with GCC. This enables support for the next + version of the C standard, expected to be published by ISO in 2018. The only + difference between the ``-std=c17`` and ``-std=c11`` language modes is the + value of the ``__STDC_VERSION__`` macro, as C17 is a bug fix release. Deprecated Compiler Flags - Modified: cfe/trunk/include/clang/Basic/LangOptions.def URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=320089&r1=320088&r2=320089&view=diff == --- cfe/trunk/include/clang/Basic/LangOptions.def (original) +++ cfe/trunk/include/clang/Basic/LangOptions.def Thu Dec 7 13:46:26 2017 @@ -1,187 +1,188 @@ -//===--- LangOptions.def - Language option database -*- C++ -*-===// -// -// The LLVM Compiler Infrastructure -// -// This file is distributed under the University of Illinois Open Source -// License. See LICENSE.TXT for details. -// -//===--===// -// -// This file defines the language options. Users of this file must -// define the LANGOPT macro to make use of this information. -// -// Optionally, the user may also define: -// -// BENIGN_LANGOPT: for options that don't affect the construction of the AST in -// any way (that is, the value can be different between an implicit module -// and the user of that module). -// -// COMPATIBLE_LANGOPT: for options that affect the construction of the AST in -// a way that doesn't prevent interoperability (that is, the value can be -// different between an explicit module and the user of that module). -// -// ENUM_LANGOPT: for options that have enumeration, rather than unsigned, type. -// -// VALUE_LANGOPT: for options that describe a value rather than a flag. -// -// BENIGN_ENUM_LANGOPT, COMPATIBLE_ENUM_LANGOPT, -// BENIGN_VALUE_LANGOPT, COMPATIBLE_VALUE_LANGOPT: combinations of the above. -// -// FIXME: Clients should be able to more easily select whether they want -// different levels of compatibility versus how to handle different kinds -// of option. -// -// The Description field should be a noun phrase, for instance "frobbing all -// widgets" or "C's implicit blintz feature". -//===--===// - -#ifndef LANGOPT -# error Define the L
Re: r320089 - Add new language mode flags for C17.
On Thu, Dec 7, 2017 at 3:05 PM, Aaron Ballman wrote: > On Thu, Dec 7, 2017 at 6:00 PM, Aaron Ballman wrote: >> On Thu, Dec 7, 2017 at 5:59 PM, Ahmed Bougacha >> wrote: >>> On Thu, Dec 7, 2017 at 2:56 PM, Richard Smith via cfe-commits >>> wrote: Looks like this might have messed up the line endings in a few files? >>> >>> Should be taken care of in r320112. >> >> Thanks, I was just getting on that. Sorry about the inadvertent churn there! > > I corrected the rest of the line endings in r320113. Thanks! -Ahmed > ~Aaron > >> >> ~Aaron >> >>> >>> -Ahmed >>> On 7 December 2017 at 13:46, Aaron Ballman via cfe-commits wrote: > > Author: aaronballman > Date: Thu Dec 7 13:46:26 2017 > New Revision: 320089 > > URL: http://llvm.org/viewvc/llvm-project?rev=320089&view=rev > Log: > Add new language mode flags for C17. > > This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode > flags for C17 and updates the value of __STDC_VERSION__ to the value based > on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is > expected that we (and GCC) will add c18 flags as aliases once the ballot > passes. > > Modified: > cfe/trunk/docs/ReleaseNotes.rst > cfe/trunk/include/clang/Basic/LangOptions.def > cfe/trunk/include/clang/Frontend/LangStandard.h > cfe/trunk/include/clang/Frontend/LangStandards.def > cfe/trunk/lib/Frontend/CompilerInvocation.cpp > cfe/trunk/lib/Frontend/InitPreprocessor.cpp > cfe/trunk/test/Driver/unknown-std.c > > Modified: cfe/trunk/docs/ReleaseNotes.rst > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=320089&r1=320088&r2=320089&view=diff > > == > --- cfe/trunk/docs/ReleaseNotes.rst (original) > +++ cfe/trunk/docs/ReleaseNotes.rst Thu Dec 7 13:46:26 2017 > @@ -121,6 +121,12 @@ New Compiler Flags >number of attributes are supported outside of C++ mode. See the Clang >attribute documentation for more information about which attributes are >supported for each syntax. > + > +- Added the ``-std=c17``, ``-std=gnu17``, and ``-std=iso9899:2017`` > language > + mode flags for compatibility with GCC. This enables support for the > next > + version of the C standard, expected to be published by ISO in 2018. The > only > + difference between the ``-std=c17`` and ``-std=c11`` language modes is > the > + value of the ``__STDC_VERSION__`` macro, as C17 is a bug fix release. > > Deprecated Compiler Flags > - > > Modified: cfe/trunk/include/clang/Basic/LangOptions.def > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=320089&r1=320088&r2=320089&view=diff > > == > --- cfe/trunk/include/clang/Basic/LangOptions.def (original) > +++ cfe/trunk/include/clang/Basic/LangOptions.def Thu Dec 7 13:46:26 2017 > @@ -1,187 +1,188 @@ > -//===--- LangOptions.def - Language option database -*- C++ > -*-===// > -// > -// The LLVM Compiler Infrastructure > -// > -// This file is distributed under the University of Illinois Open Source > -// License. See LICENSE.TXT for details. > -// > > -//===--===// > -// > -// This file defines the language options. Users of this file must > -// define the LANGOPT macro to make use of this information. > -// > -// Optionally, the user may also define: > -// > -// BENIGN_LANGOPT: for options that don't affect the construction of the > AST in > -// any way (that is, the value can be different between an implicit > module > -// and the user of that module). > -// > -// COMPATIBLE_LANGOPT: for options that affect the construction of the > AST in > -// a way that doesn't prevent interoperability (that is, the value > can be > -// different between an explicit module and the user of that module). > -// > -// ENUM_LANGOPT: for options that have enumeration, rather than unsigned, > type. > -// > -// VALUE_LANGOPT: for options that describe a value rather than a flag. > -// > -// BENIGN_ENUM_LANGOPT, COMPATIBLE_ENUM_LANGOPT, > -// BENIGN_VALUE_LANGOPT, COMPATIBLE_VALUE_LANGOPT: combinations of the > above. > -// > -// FIXME: Clients should be able to more easily select whether they want > -// different levels of compatibility versus how to handle different kinds > -// of option. > -// > -// The Description field should be a noun phrase, for instance "frobbing > al
Re: r315996 - [CMake][OpenMP] Customize default offloading arch
Hi Jonas,
On Tue, Oct 17, 2017 at 6:37 AM, Jonas Hahnfeld via cfe-commits
wrote:
> Author: hahnfeld
> Date: Tue Oct 17 06:37:36 2017
> New Revision: 315996
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315996&view=rev
> Log:
> [CMake][OpenMP] Customize default offloading arch
>
> For the shuffle instructions in reductions we need at least sm_30
> but the user may want to customize the default architecture.
>
> Differential Revision: https://reviews.llvm.org/D38883
>
> Modified:
> cfe/trunk/CMakeLists.txt
> cfe/trunk/include/clang/Config/config.h.cmake
> cfe/trunk/lib/Driver/ToolChains/Cuda.cpp
> cfe/trunk/lib/Driver/ToolChains/Cuda.h
>
> Modified: cfe/trunk/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=315996&r1=315995&r2=315996&view=diff
> ==
> --- cfe/trunk/CMakeLists.txt (original)
> +++ cfe/trunk/CMakeLists.txt Tue Oct 17 06:37:36 2017
> @@ -235,6 +235,17 @@ endif()
> set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>"Default OpenMP runtime used by -fopenmp.")
>
> +# OpenMP offloading requires at least sm_30 because we use shuffle
> instructions
> +# to generate efficient code for reductions.
> +set(CLANG_OPENMP_NVPTX_DEFAULT_ARCH "sm_30" CACHE STRING
> + "Default architecture for OpenMP offloading to Nvidia GPUs.")
> +string(REGEX MATCH "^sm_([0-9]+)$" MATCHED_ARCH
> "${CLANG_OPENMP_NVPTX_DEFAULT_ARCH}")
> +if (NOT DEFINED MATCHED_ARCH OR "${CMAKE_MATCH_1}" LESS 30)
> + message(WARNING "Resetting default architecture for OpenMP offloading to
> Nvidia GPUs to sm_30")
This warning is pretty noisy and doesn't affect most people: I don't
know what it means but I get it in every cmake run.
Can we somehow restrict or disable it?
Thanks!
-Ahmed
> + set(CLANG_OPENMP_NVPTX_DEFAULT_ARCH "sm_30" CACHE STRING
> +"Default architecture for OpenMP offloading to Nvidia GPUs." FORCE)
> +endif()
> +
> set(CLANG_VENDOR ${PACKAGE_VENDOR} CACHE STRING
>"Vendor-specific text for showing with version information.")
>
>
> Modified: cfe/trunk/include/clang/Config/config.h.cmake
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Config/config.h.cmake?rev=315996&r1=315995&r2=315996&view=diff
> ==
> --- cfe/trunk/include/clang/Config/config.h.cmake (original)
> +++ cfe/trunk/include/clang/Config/config.h.cmake Tue Oct 17 06:37:36 2017
> @@ -20,6 +20,9 @@
> /* Default OpenMP runtime used by -fopenmp. */
> #define CLANG_DEFAULT_OPENMP_RUNTIME "${CLANG_DEFAULT_OPENMP_RUNTIME}"
>
> +/* Default architecture for OpenMP offloading to Nvidia GPUs. */
> +#define CLANG_OPENMP_NVPTX_DEFAULT_ARCH "${CLANG_OPENMP_NVPTX_DEFAULT_ARCH}"
> +
> /* Multilib suffix for libdir. */
> #define CLANG_LIBDIR_SUFFIX "${CLANG_LIBDIR_SUFFIX}"
>
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Cuda.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Cuda.cpp?rev=315996&r1=315995&r2=315996&view=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Cuda.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Cuda.cpp Tue Oct 17 06:37:36 2017
> @@ -542,9 +542,9 @@ CudaToolChain::TranslateArgs(const llvm:
>// flags are not duplicated.
>// Also append the compute capability.
>if (DeviceOffloadKind == Action::OFK_OpenMP) {
> -for (Arg *A : Args){
> +for (Arg *A : Args) {
>bool IsDuplicate = false;
> - for (Arg *DALArg : *DAL){
> + for (Arg *DALArg : *DAL) {
> if (A == DALArg) {
>IsDuplicate = true;
>break;
> @@ -555,14 +555,9 @@ CudaToolChain::TranslateArgs(const llvm:
> }
>
> StringRef Arch = DAL->getLastArgValue(options::OPT_march_EQ);
> -if (Arch.empty()) {
> - // Default compute capability for CUDA toolchain is the
> - // lowest compute capability supported by the installed
> - // CUDA version.
> - DAL->AddJoinedArg(nullptr,
> - Opts.getOption(options::OPT_march_EQ),
> - CudaInstallation.getLowestExistingArch());
> -}
> +if (Arch.empty())
> + DAL->AddJoinedArg(nullptr, Opts.getOption(options::OPT_march_EQ),
> +CLANG_OPENMP_NVPTX_DEFAULT_ARCH);
>
> return DAL;
>}
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Cuda.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Cuda.h?rev=315996&r1=315995&r2=315996&view=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Cuda.h (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Cuda.h Tue Oct 17 06:37:36 2017
> @@ -76,17 +76,6 @@ public:
>std::string getLibDeviceFile(StringRef Gpu) const {
> return LibDeviceMap.lookup(Gpu);
>}
> - /// \brief Get lowest available compute capability
> - /// for
[clang] [llvm] [clang-tools-extra] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -882,8 +882,11 @@ class AsmPrinter : public MachineFunctionPass {
GCMetadataPrinter *getOrCreateGCPrinter(GCStrategy &S);
void emitGlobalAlias(Module &M, const GlobalAlias &GA);
- void emitGlobalIFunc(Module &M, const GlobalIFunc &GI);
+protected:
+ virtual void emitGlobalIFunc(Module &M, const GlobalIFunc &GI);
ahmedbougacha wrote:
Probably deserves to be with `emitGlobalVariable` or "overridable hooks" above?
(but maybe the hooks can be finer-grained, see later comment)
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang-tools-extra] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -144,7 +144,12 @@ bool CallLowering::lowerCall(MachineIRBuilder &MIRBuilder,
const CallBase &CB,
// Try looking through a bitcast from one function type to another.
// Commonly happens with calls to objc_msgSend().
const Value *CalleeV = CB.getCalledOperand()->stripPointerCasts();
- if (const Function *F = dyn_cast(CalleeV))
+ if (const GlobalIFunc *IF = dyn_cast(CalleeV);
+ IF && MF.getTarget().getTargetTriple().isOSBinFormatMachO()) {
ahmedbougacha wrote:
Heh, I did a double-take on the nesting; maybe embrace the dumber
`isa<>`/`cast<>`? ;)
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -1809,6 +1814,255 @@ void AArch64AsmPrinter::emitInstruction(const
MachineInstr *MI) {
EmitToStreamer(*OutStreamer, TmpInst);
}
+void AArch64AsmPrinter::emitGlobalIFunc(Module &M, const GlobalIFunc &GI) {
+ if (!TM.getTargetTriple().isOSBinFormatMachO())
+return AsmPrinter::emitGlobalIFunc(M, GI);
ahmedbougacha wrote:
How about having all the lazy/stub symbol machinery in AsmPrinter proper, and
only having target-specific "emit macho stub/helper body" overridable hooks?
I ask because I wondered "when would you have `!MAI->getWeakRefDirective()` for
macho?" and noticed that's from the base anyway. I imagine moving this
wouldn't change that, because this'd still be in a macho-specific bit there.
But at least if the ELF base changes, the macho version would be right there
next to it ;) WDYT?
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang-tools-extra] [llvm] Support IFuncs on Darwin platforms (PR #73686)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/73686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libc] [lld] [clang] [libcxx] [lldb] [mlir] [clang-tools-extra] [libcxxabi] [flang] [llvm] [openmp] [compiler-rt] [llvm] Support IFuncs on Darwin platforms (PR #73686)
https://github.com/ahmedbougacha commented: Only a couple minor comments, LG otherwise, thanks! The Subtarget weirdness is unfortunate but I can't say I have a better alternative https://github.com/llvm/llvm-project/pull/73686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] [clang] [libcxxabi] [lld] [flang] [openmp] [mlir] [llvm] [libc] [compiler-rt] [clang-tools-extra] [lldb] [llvm] Support IFuncs on Darwin platforms (PR #73686)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/73686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[lldb] [clang] [openmp] [lld] [compiler-rt] [libc] [flang] [libcxxabi] [llvm] [libcxx] [clang-tools-extra] [mlir] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -599,6 +599,26 @@ class AsmPrinter : public MachineFunctionPass {
/// instructions in verbose mode.
virtual void emitImplicitDef(const MachineInstr *MI) const;
+ /// getSubtargetInfo() cannot be used where this is needed because we don't
+ /// have a MachineFunction when we're lowering a GlobalIFunc, and
+ /// getSubtargetInfo requires one. Override the implementation in targets
+ /// that support the Mach-O IFunc lowering.
+ virtual const MCSubtargetInfo *getIFuncMCSubtargetInfo() const {
+return nullptr;
+ }
+
+ virtual void emitMachOIFuncStubBody(Module &M, const GlobalIFunc &GI,
+ MCSymbol *LazyPointer) {
ahmedbougacha wrote:
Maybe pass the symbol string directly, since the implementations make their own
symbol references anyway? That way you also don't have to do the awkward
de-mangle/re-mangle dance with the +1
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [libcxxabi] [compiler-rt] [mlir] [openmp] [lldb] [flang] [clang-tools-extra] [libc] [lld] [libcxx] [clang] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -2147,24 +2148,80 @@ void AsmPrinter::emitGlobalIFunc(Module &M, const
GlobalIFunc &GI) {
assert(!TM.getTargetTriple().isOSBinFormatXCOFF() &&
"IFunc is not supported on AIX.");
- MCSymbol *Name = getSymbol(&GI);
+ auto EmitLinkage = [&](MCSymbol *Sym) {
+if (GI.hasExternalLinkage() || !MAI->getWeakRefDirective())
+ OutStreamer->emitSymbolAttribute(Sym, MCSA_Global);
+else if (GI.hasWeakLinkage() || GI.hasLinkOnceLinkage())
+ OutStreamer->emitSymbolAttribute(Sym, MCSA_WeakReference);
+else
+ assert(GI.hasLocalLinkage() && "Invalid ifunc linkage");
+ };
- if (GI.hasExternalLinkage() || !MAI->getWeakRefDirective())
-OutStreamer->emitSymbolAttribute(Name, MCSA_Global);
- else if (GI.hasWeakLinkage() || GI.hasLinkOnceLinkage())
-OutStreamer->emitSymbolAttribute(Name, MCSA_WeakReference);
- else
-assert(GI.hasLocalLinkage() && "Invalid ifunc linkage");
+ if (TM.getTargetTriple().isOSBinFormatELF()) {
+MCSymbol *Name = getSymbol(&GI);
+EmitLinkage(Name);
+OutStreamer->emitSymbolAttribute(Name, MCSA_ELF_TypeIndFunction);
+emitVisibility(Name, GI.getVisibility());
+
+// Emit the directives as assignments aka .set:
+const MCExpr *Expr = lowerConstant(GI.getResolver());
+OutStreamer->emitAssignment(Name, Expr);
+MCSymbol *LocalAlias = getSymbolPreferLocal(GI);
+if (LocalAlias != Name)
+ OutStreamer->emitAssignment(LocalAlias, Expr);
+ } else if (TM.getTargetTriple().isOSBinFormatMachO() &&
ahmedbougacha wrote:
early return with if->fatal_error, for indentation?
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[lld] [clang] [libcxx] [llvm] [libc] [mlir] [libcxxabi] [openmp] [lldb] [clang-tools-extra] [compiler-rt] [flang] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -2169,8 +2169,11 @@ void AsmPrinter::emitGlobalIFunc(Module &M, const
GlobalIFunc &GI) {
MCSymbol *LocalAlias = getSymbolPreferLocal(GI);
if (LocalAlias != Name)
OutStreamer->emitAssignment(LocalAlias, Expr);
- } else if (TM.getTargetTriple().isOSBinFormatMachO() &&
- getIFuncMCSubtargetInfo()) {
+
+return;
+ }
+
+ if (TM.getTargetTriple().isOSBinFormatMachO() && getIFuncMCSubtargetInfo()) {
ahmedbougacha wrote:
oh I meant literally:
```
if (!TM.getTargetTriple().isOSBinFormatMachO() || !getIFuncMCSubtargetInfo())
llvm::report_fatal_error("IFuncs are not supported on this platform");
```
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [libc] [openmp] [lld] [compiler-rt] [libcxxabi] [clang] [libcxx] [lldb] [mlir] [flang] [llvm] [llvm] Support IFuncs on Darwin platforms (PR #73686)
https://github.com/ahmedbougacha approved this pull request. Neat, ty! https://github.com/llvm/llvm-project/pull/73686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] AArch64: add support for currently released Apple CPUs. (PR #73499)
https://github.com/ahmedbougacha approved this pull request. https://github.com/llvm/llvm-project/pull/73499 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha updated https://github.com/llvm/llvm-project/pull/65996 >From c4e7c86eb967b4313e19587e33fdc6b50c8cd6a7 Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Wed, 16 Aug 2023 09:17:12 -0700 Subject: [PATCH] [AArch64][PAC] Support and document ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, in addition to these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 265 ++ clang/include/clang/Basic/Builtins.def| 8 + clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 ++ clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 + clang/lib/Driver/ToolChains/Clang.cpp | 5 + clang/lib/Frontend/CompilerInvocation.cpp | 14 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 167 +++ clang/lib/Sema/SemaChecking.cpp | 182 clang/test/CodeGen/ptrauth-intrinsics.c | 73 + clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 +++ clang/test/Sema/ptrauth.c | 126 + llvm/docs/PointerAuth.md | 3 + 25 files changed, 1013 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 23a7f4f5d5b926..00657e6c9bfe11 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4206,6 +4207,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 00..96bcf2cd5fc824 --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3 PAuth) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identifi
[clang] 89c94c2 - [clang][Driver] Get darwin -Xarch_ working for subtypes, again.
Author: Ahmed Bougacha
Date: 2022-03-09T18:21:45-08:00
New Revision: 89c94c242c7ddcc700aba6af7243dcac7a9a4ef2
URL:
https://github.com/llvm/llvm-project/commit/89c94c242c7ddcc700aba6af7243dcac7a9a4ef2
DIFF:
https://github.com/llvm/llvm-project/commit/89c94c242c7ddcc700aba6af7243dcac7a9a4ef2.diff
LOG: [clang][Driver] Get darwin -Xarch_ working for subtypes, again.
35ca7d9ddf4 broke 471c4f829934 for -arch flags that don't map 1:1
to the triple arch. This has been broken for the many years since.
It hasn't mattered much since then, mostly because few people use it,
but also because it works for x86_64/i386, armv7/armv7s
don't differ much, arm64 is its own arch, and arm64/arm64_32 have
different arches (and it's a rare combination anyway).
But arm64/arm64e exposes this issue again.
Patch by: Justin Bogner
with some added tests.
Added:
Modified:
clang/lib/Driver/ToolChains/Darwin.cpp
clang/test/Driver/darwin-xarch.c
Removed:
diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 005236c4476f4..a11cd3fbaa71c 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2487,12 +2487,9 @@ DerivedArgList *MachO::TranslateArgs(const
DerivedArgList &Args,
if (A->getOption().matches(options::OPT_Xarch__)) {
// Skip this argument unless the architecture matches either the
toolchain
// triple arch, or the arch being bound.
- llvm::Triple::ArchType XarchArch =
- tools::darwin::getArchTypeForMachOArchName(A->getValue(0));
- if (!(XarchArch == getArch() ||
-(!BoundArch.empty() &&
- XarchArch ==
- tools::darwin::getArchTypeForMachOArchName(BoundArch
+ StringRef XarchArch = A->getValue(0);
+ if (!(XarchArch == getArchName() ||
+(!BoundArch.empty() && XarchArch == BoundArch)))
continue;
Arg *OriginalArg = A;
diff --git a/clang/test/Driver/darwin-xarch.c
b/clang/test/Driver/darwin-xarch.c
index 3014236f8ccda..0df17fda7b0e3 100644
--- a/clang/test/Driver/darwin-xarch.c
+++ b/clang/test/Driver/darwin-xarch.c
@@ -18,3 +18,32 @@
// RUN: FileCheck --check-prefix=CHECK-ARMV7-LINK < %t %s
//
// CHECK-ARMV7-LINK: ld{{.*}} "-arch" "armv7"{{.*}} "-some-linker-arg"
+
+
+// RUN: %clang -target armv7s-apple-ios7 -### \
+// RUN: -arch armv7 -Xarch_armv7 -DARMV7=1 \
+// RUN: -arch armv7s -Xarch_armv7s -DARMV7S=1 \
+// RUN: -c %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-ARMV7S < %t %s
+//
+// CHECK-ARMV7S: clang{{.*}}" "-cc1" "-triple" "thumbv7-apple-ios7.0.0"
+// CHECK-ARMV7S-NOT: "-D" "ARMV7S=1"
+// CHECK-ARMV7S-SAME: "-D" "ARMV7=1"
+//
+// CHECK-ARMV7S: clang{{.*}}" "-cc1" "-triple" "thumbv7s-apple-ios7.0.0"
+// CHECK-ARMV7S-NOT: "-D" "ARMV7=1"
+// CHECK-ARMV7S-SAME: "-D" "ARMV7S=1"
+
+// RUN: %clang -target arm64-apple-ios14 -### \
+// RUN: -arch arm64 -Xarch_arm64 -DARM64=1 \
+// RUN: -arch arm64e -Xarch_arm64e -DARM64E=1 \
+// RUN: -c %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-ARM64 < %t %s
+//
+// CHECK-ARM64: clang{{.*}}" "-cc1" "-triple" "arm64-apple-ios14.0.0"
+// CHECK-ARM64-NOT: "-D" "ARM64E=1"
+// CHECK-ARM64-SAME: "-D" "ARM64=1"
+//
+// CHECK-ARM64: clang{{.*}}" "-cc1" "-triple" "arm64e-apple-ios14.0.0"
+// CHECK-ARM64-NOT: "-D" "ARM64=1"
+// CHECK-ARM64-SAME: "-D" "ARM64E=1"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 6ba68a5 - [clang][Driver] Use a VersionTuple for darwin linker version checks.
Author: Ahmed Bougacha
Date: 2022-02-08T14:30:39-08:00
New Revision: 6ba68a5fc34271c85f438217f50e165cb0158c04
URL:
https://github.com/llvm/llvm-project/commit/6ba68a5fc34271c85f438217f50e165cb0158c04
DIFF:
https://github.com/llvm/llvm-project/commit/6ba68a5fc34271c85f438217f50e165cb0158c04.diff
LOG: [clang][Driver] Use a VersionTuple for darwin linker version checks.
This unifies a couple spots that did it manually by checking the
flag directly.
It does mean that we're now dropping the 5th component, but that's
not used in any of these checks, and to my knowledge it's never been
used in ld64.
Added:
Modified:
clang/lib/Driver/ToolChains/Darwin.cpp
clang/lib/Driver/ToolChains/Darwin.h
clang/test/Driver/darwin-ld.c
Removed:
diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp
b/clang/lib/Driver/ToolChains/Darwin.cpp
index e71511747e44d..df860ccc6be4f 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -209,19 +209,19 @@ static bool shouldLinkerNotDedup(bool IsLinkerOnlyAction,
const ArgList &Args) {
void darwin::Linker::AddLinkArgs(Compilation &C, const ArgList &Args,
ArgStringList &CmdArgs,
const InputInfoList &Inputs,
- unsigned Version[5], bool LinkerIsLLD) const {
+ VersionTuple Version, bool LinkerIsLLD) const
{
const Driver &D = getToolChain().getDriver();
const toolchains::MachO &MachOTC = getMachOToolChain();
// Newer linkers support -demangle. Pass it if supported and not disabled by
// the user.
- if ((Version[0] >= 100 || LinkerIsLLD) &&
+ if ((Version >= VersionTuple(100) || LinkerIsLLD) &&
!Args.hasArg(options::OPT_Z_Xlinker__no_demangle))
CmdArgs.push_back("-demangle");
// FIXME: Pass most of the flags below that check Version if LinkerIsLLD too.
- if (Args.hasArg(options::OPT_rdynamic) && Version[0] >= 137)
+ if (Args.hasArg(options::OPT_rdynamic) && Version >= VersionTuple(137))
CmdArgs.push_back("-export_dynamic");
// If we are using App Extension restrictions, pass a flag to the linker
@@ -230,7 +230,7 @@ void darwin::Linker::AddLinkArgs(Compilation &C, const
ArgList &Args,
options::OPT_fno_application_extension, false))
CmdArgs.push_back("-application_extension");
- if (D.isUsingLTO() && Version[0] >= 116 && NeedsTempPath(Inputs)) {
+ if (D.isUsingLTO() && Version >= VersionTuple(116) && NeedsTempPath(Inputs))
{
std::string TmpPathName;
if (D.getLTOMode() == LTOK_Full) {
// If we are using full LTO, then automatically create a temporary file
@@ -259,7 +259,7 @@ void darwin::Linker::AddLinkArgs(Compilation &C, const
ArgList &Args,
// clang version won't work anyways.
// lld is built at the same revision as clang and statically links in
// LLVM libraries, so it doesn't need libLTO.dylib.
- if (Version[0] >= 133 && !LinkerIsLLD) {
+ if (Version >= VersionTuple(133) && !LinkerIsLLD) {
// Search for libLTO in /../lib/libLTO.dylib
StringRef P = llvm::sys::path::parent_path(D.Dir);
SmallString<128> LibLTOPath(P);
@@ -270,7 +270,7 @@ void darwin::Linker::AddLinkArgs(Compilation &C, const
ArgList &Args,
}
// ld64 version 262 and above run the deduplicate pass by default.
- if (Version[0] >= 262 && shouldLinkerNotDedup(C.getJobs().empty(), Args))
+ if (Version >= VersionTuple(262) &&
shouldLinkerNotDedup(C.getJobs().empty(), Args))
CmdArgs.push_back("-no_deduplicate");
// Derived from the "link" spec.
@@ -342,7 +342,7 @@ void darwin::Linker::AddLinkArgs(Compilation &C, const
ArgList &Args,
Args.AddAllArgs(CmdArgs, options::OPT_init);
// Add the deployment target.
- if (Version[0] >= 520 || LinkerIsLLD)
+ if (Version >= VersionTuple(520) || LinkerIsLLD)
MachOTC.addPlatformVersionArgs(Args, CmdArgs);
else
MachOTC.addMinVersionArgs(Args, CmdArgs);
@@ -368,7 +368,8 @@ void darwin::Linker::AddLinkArgs(Compilation &C, const
ArgList &Args,
// Check if the toolchain supports bitcode build flow.
if (MachOTC.SupportsEmbeddedBitcode()) {
CmdArgs.push_back("-bitcode_bundle");
- if (C.getDriver().embedBitcodeMarkerOnly() && Version[0] >= 278) {
+ if (C.getDriver().embedBitcodeMarkerOnly() &&
+ Version >= VersionTuple(278)) {
CmdArgs.push_back("-bitcode_process_mode");
CmdArgs.push_back("marker");
}
@@ -548,12 +549,7 @@ void darwin::Linker::ConstructJob(Compilation &C, const
JobAction &JA,
return;
}
- unsigned Version[5] = {0, 0, 0, 0, 0};
- if (Arg *A = Args.getLastArg(options::OPT_mlinker_version_EQ)) {
-if (!Driver::GetReleaseVersion(A->getValue(), Version))
- getToolChain().getDriver().Diag(diag::err_drv_invalid_version_number)
- << A->getAsString(Args);
-
[clang] ca9f0ec - [clang] Document objc_unsafeClaimAutoreleasedReturnValue.
Author: Ahmed Bougacha Date: 2022-02-08T14:30:39-08:00 New Revision: ca9f0ec1a30b899ce9df3d2173aa9a295b510509 URL: https://github.com/llvm/llvm-project/commit/ca9f0ec1a30b899ce9df3d2173aa9a295b510509 DIFF: https://github.com/llvm/llvm-project/commit/ca9f0ec1a30b899ce9df3d2173aa9a295b510509.diff LOG: [clang] Document objc_unsafeClaimAutoreleasedReturnValue. This has been added a few years ago but wasn't listed here. Added: Modified: clang/docs/AutomaticReferenceCounting.rst Removed: diff --git a/clang/docs/AutomaticReferenceCounting.rst b/clang/docs/AutomaticReferenceCounting.rst index 9b0b6b86eb11e..5e40fa837b1aa 100644 --- a/clang/docs/AutomaticReferenceCounting.rst +++ b/clang/docs/AutomaticReferenceCounting.rst @@ -2380,8 +2380,10 @@ the current pool, and returns an opaque "handle" to it. If ``value`` is null, this call has no effect. Otherwise, it makes a best effort to hand off ownership of a retain count on the object to a call to :ref:`objc_retainAutoreleasedReturnValue -` for the same object in an -enclosing call frame. If this is not possible, the object is autoreleased as +` (or +:ref:`objc_unsafeClaimAutoreleasedReturnValue +`) for the same object in +an enclosing call frame. If this is not possible, the object is autoreleased as above. Always returns ``value``. @@ -2579,8 +2581,8 @@ Always returns ``value``. If ``value`` is null, this call has no effect. Otherwise, it attempts to accept a hand off of a retain count from a call to :ref:`objc_autoreleaseReturnValue ` on -``value`` in a recently-called function or something it calls. If that fails, -it performs a retain operation exactly like :ref:`objc_retain +``value`` in a recently-called function or something it tail-calls. If that +fails, it performs a retain operation exactly like :ref:`objc_retain `. Always returns ``value``. @@ -2639,3 +2641,21 @@ registration updated to point to ``value``. Returns the value of ``object`` after the call. +.. _arc.runtime.objc_unsafeClaimAutoreleasedReturnValue: + +``id objc_unsafeClaimAutoreleasedReturnValue(id value);`` +- + +*Precondition:* ``value`` is null or a pointer to a valid object. + +If ``value`` is null, this call has no effect. Otherwise, it attempts to +accept a hand off of a retain count from a call to +:ref:`objc_autoreleaseReturnValue ` on +``value`` in a recently-called function or something it tail-calls (in a manner +similar to :ref:`objc_retainAutoreleasedReturnValue +`). If that succeeds, +it performs a release operation exactly like :ref:`objc_release +`. If the handoff fails, this call has no effect. + +Always returns ``value``. + ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CodeGen][AArch64][FMV] PAC the stub_helper's frame on arm64e (PR #84704)
@@ -2085,6 +2099,37 @@ void
AArch64AsmPrinter::emitMachOIFuncStubHelperBody(Module &M,
.addImm(2),
*STI);
+ if (TM.getTargetTriple().isArm64e()) {
+// autibsp
ahmedbougacha wrote:
Leave the tail-call checking for the general tail-call checking patches, no?
https://github.com/llvm/llvm-project/pull/84704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha updated https://github.com/llvm/llvm-project/pull/65996 >From 1492d6362a1a4f6d65fb7001bdefb5250f30754e Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Wed, 16 Aug 2023 09:17:12 -0700 Subject: [PATCH] [AArch64][PAC] Support and document ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, in addition to these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 485 ++ clang/include/clang/Basic/Builtins.td | 37 ++ clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 + clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 +++ clang/lib/Driver/ToolChains/Clang.cpp | 4 + clang/lib/Frontend/CompilerInvocation.cpp | 14 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 185 +++ clang/lib/Sema/SemaChecking.cpp | 197 +++ clang/test/CodeGen/ptrauth-intrinsics.c | 73 +++ clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 ++ clang/test/Sema/ptrauth.c | 126 + llvm/docs/PointerAuth.md | 3 + 25 files changed, 1294 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 225736009d4869..13d7261d83d7f1 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4318,6 +4319,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 00..19b3384293aede --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,485 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic +protection against exploiting a broad class of memory bugs to take control of +program execution. When adopted consistently in a language ABI, it provides +a form of relatively fine-grained control flow integrity (CFI) check that +resists both return-oriented programming (ROP) and jump-oriented programming +(JOP) attacks. + +While pointer authentication can be implemented purely in software, direct +hardware support (e.g. as provided by Armv8.3 PAuth) can dramatically improve +performance and code size. Similarly, while pointer authentication +can be implemented on any architecture, taking advantage of the (typically) +excess addressing range of a target with 64-bit pointers minimizes the impact +on memory performance and can allow interoperation with existing code (by +disabling pointer authentication dynamically). This document will generally +attempt to present the pointer authentication feature independent of any +hardware implementation or ABI. Considerations that are +implementation-specific are clearly identified throughout. + +Note that th
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CodeGen][AArch64][FMV] PAC the stub_helper's frame on arm64e (PR #84704)
@@ -2085,6 +2099,37 @@ void
AArch64AsmPrinter::emitMachOIFuncStubHelperBody(Module &M,
.addImm(2),
*STI);
+ if (TM.getTargetTriple().isArm64e()) {
+// autibsp
ahmedbougacha wrote:
There is not, but send me your patch and I'll tack it onto the relevant commit
(and split the tail-call check emission into a helper)
https://github.com/llvm/llvm-project/pull/84704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha updated https://github.com/llvm/llvm-project/pull/65996 >From c5cde09a5ea4a4cfcf3287f7462c38335493c02d Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Wed, 16 Aug 2023 09:17:12 -0700 Subject: [PATCH] [AArch64][PAC] Support and document ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, in addition to these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 485 ++ clang/include/clang/Basic/Builtins.td | 37 ++ clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 + clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 +++ clang/lib/Driver/ToolChains/Clang.cpp | 4 + clang/lib/Frontend/CompilerInvocation.cpp | 14 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 185 +++ clang/lib/Sema/SemaChecking.cpp | 197 +++ clang/test/CodeGen/ptrauth-intrinsics.c | 73 +++ clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 ++ clang/test/Sema/ptrauth.c | 126 + llvm/docs/PointerAuth.md | 3 + 25 files changed, 1294 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 711baf45f449a05..c818a1d805f51e1 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4244,6 +4245,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 000..0ecdfb34e8cf72a --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,485 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic +protection against exploiting a broad class of memory bugs to take control of +program execution. When adopted consistently in a language ABI, it provides +a form of relatively fine-grained control flow integrity (CFI) check that +resists both return-oriented programming (ROP) and jump-oriented programming +(JOP) attacks. + +While pointer authentication can be implemented purely in software, direct +hardware support (e.g. as provided by Armv8.3 PAuth) can dramatically improve +performance and code size. Similarly, while pointer authentication +can be implemented on any architecture, taking advantage of the (typically) +excess addressing range of a target with 64-bit pointers minimizes the impact +on memory performance and can allow interoperation with existing code (by +disabling pointer authentication dynamically). This document will generally +attempt to present the pointer authentication feature independent of any +hardware implementation or ABI. Considerations that are +implementation-specific are clearly identified throughout. + +Note tha
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3 PAuth) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **PAuth** (sometimes referred to as **PAC**, for Pointer Authentication Codes) is an AArch64 architecture extension that provides hardware support for pointer authentication. + +- **ARMv8.3** is an AArch64 architecture revision that makes PAuth mandatory. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI (not yet fully stable) for implementing pointer authentication using PAuth on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It will eventually present a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. ahmedbougacha wrote: Yeah, I added "concrete" when describing the key value, as opposed to "abstract" key names/IDs such as "ASIA". https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3 PAuth) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **PAuth** (sometimes referred to as **PAC**, for Pointer Authentication Codes) is an AArch64 architecture extension that provides hardware support for pointer authentication. + +- **ARMv8.3** is an AArch64 architecture revision that makes PAuth mandatory. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI (not yet fully stable) for implementing pointer authentication using PAuth on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It will eventually present a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficient
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3 PAuth) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **PAuth** (sometimes referred to as **PAC**, for Pointer Authentication Codes) is an AArch64 architecture extension that provides hardware support for pointer authentication. + +- **ARMv8.3** is an AArch64 architecture revision that makes PAuth mandatory. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI (not yet fully stable) for implementing pointer authentication using PAuth on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It will eventually present a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficient
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
ahmedbougacha wrote: Updated, tried to address all the comments; let me know if I missed something! https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] f77c948 - [Triple][MachO] Define "arm64e", an AArch64 subarch for Pointer Auth.
Author: Ahmed Bougacha
Date: 2020-12-03T07:53:59-08:00
New Revision: f77c948d56b09b839262e258af5c6ad701e5b168
URL:
https://github.com/llvm/llvm-project/commit/f77c948d56b09b839262e258af5c6ad701e5b168
DIFF:
https://github.com/llvm/llvm-project/commit/f77c948d56b09b839262e258af5c6ad701e5b168.diff
LOG: [Triple][MachO] Define "arm64e", an AArch64 subarch for Pointer Auth.
This also teaches MachO writers/readers about the MachO cpu subtype,
beyond the minimal subtype reader support present at the moment.
This also defines a preprocessor macro to allow users to distinguish
__arm64__ from __arm64e__.
arm64e defaults to an "apple-a12" CPU, which supports v8.3a, allowing
pointer-authentication codegen.
It also currently defaults to ios14 and macos11.
Differential Revision: https://reviews.llvm.org/D87095
Added:
clang/test/Preprocessor/arm64e.c
llvm/test/MC/AArch64/arm64e-subtype.s
llvm/test/MC/AArch64/arm64e.s
llvm/test/tools/llvm-dwarfdump/AArch64/arm64e.ll
llvm/test/tools/llvm-readobj/macho-arm64e.test
Modified:
clang/lib/Basic/Targets/AArch64.cpp
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/lib/Driver/ToolChains/Darwin.cpp
clang/test/Driver/aarch64-cpus.c
clang/test/Driver/arclite-link.c
clang/test/Driver/target-triple-deployment.c
llvm/include/llvm/ADT/Triple.h
llvm/lib/BinaryFormat/MachO.cpp
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/LTO/LTOModule.cpp
llvm/lib/Object/MachOObjectFile.cpp
llvm/lib/Support/ARMTargetParser.cpp
llvm/lib/Support/Triple.cpp
llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCTargetDesc.cpp
llvm/test/MC/MachO/AArch64/arm-darwin-version-min-load-command.s
llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
llvm/unittests/ADT/TripleTest.cpp
llvm/utils/UpdateTestChecks/asm.py
Removed:
diff --git a/clang/lib/Basic/Targets/AArch64.cpp
b/clang/lib/Basic/Targets/AArch64.cpp
index abdd424ea048..c8162dd55220 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -874,6 +874,9 @@ void DarwinAArch64TargetInfo::getOSDefines(const
LangOptions &Opts,
Builder.defineMacro("__arm64", "1");
Builder.defineMacro("__arm64__", "1");
+ if (Triple.isArm64e())
+Builder.defineMacro("__arm64e__", "1");
+
getDarwinDefines(Builder, Opts, Triple, PlatformName, PlatformMinVersion);
}
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 85ab05cb7021..11b78a14fe47 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -232,8 +232,11 @@ StringRef ToolChain::getDefaultUniversalArchName() const {
// the same as the ones that appear in the triple. Roughly speaking, this is
// an inverse of the darwin::getArchTypeForDarwinArchName() function.
switch (Triple.getArch()) {
- case llvm::Triple::aarch64:
+ case llvm::Triple::aarch64: {
+if (getTriple().isArm64e())
+ return "arm64e";
return "arm64";
+ }
case llvm::Triple::aarch64_32:
return "arm64_32";
case llvm::Triple::ppc:
@@ -706,6 +709,9 @@ std::string ToolChain::ComputeLLVMTriple(const ArgList
&Args,
if (!Triple.isOSBinFormatMachO())
return getTripleString();
+if (Triple.isArm64e())
+ return getTripleString();
+
// FIXME: older versions of ld64 expect the "arm64" component in the actual
// triple string and query it to determine whether an LTO file can be
// handled. Remove this when we don't care any more.
diff --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index 06bb705a3721..0fc531b8c3a0 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -40,7 +40,12 @@ std::string aarch64::getAArch64TargetCPU(const ArgList &Args,
// Handle CPU name is 'native'.
if (CPU == "native")
return std::string(llvm::sys::getHostCPUName());
- else if (CPU.size())
+
+ // arm64e requires v8.3a and only runs on apple-a12 and later CPUs.
+ if (Triple.isArm64e())
+return "apple-a12";
+
+ if (CPU.size())
return CPU;
if (Triple.isTargetMachineMac() &&
diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 9f8560356405..eb7bd4aec898 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -7,6 +7,7 @@
//===--===//
#include "Darwin.h"
+#include "Arch/AArch64.h"
#include "Arch/ARM.h"
#include "CommonArgs.h"
#include "clang/Basic/AlignedAllocation.h"
@@ -58,7 +59,7 @@ llvm::Triple::ArchType
darwin::getArchTypeForMachOArchName(StringRef Str) {
.Cases("arm", "armv4t", "armv5", "armv6", "armv6m", llvm::Triple::arm)
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha labeled https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha created https://github.com/llvm/llvm-project/pull/65996: This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, as well as these builtins. (Replaces https://reviews.llvm.org/D112941) >From 6d135911787111dff1845a0c55e3d0ec0f280787 Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Mon, 11 Sep 2023 11:41:47 -0700 Subject: [PATCH] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, as well as these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 548 ++ clang/include/clang/Basic/Builtins.def| 8 + clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 + clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/Module.cpp| 4 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 +++ clang/lib/Driver/ToolChains/Clang.cpp | 5 + clang/lib/Frontend/CompilerInvocation.cpp | 13 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 167 ++ clang/lib/Sema/SemaChecking.cpp | 182 ++ clang/test/CodeGen/ptrauth-intrinsics.c | 73 +++ .../module.modulemap | 8 + .../ptrauth-include-from-darwin/ptrauth.h | 1 + .../ptrauth-include-from-darwin/stddef.h | 1 + .../Modules/ptrauth-include-from-darwin.m | 6 + clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 ++ clang/test/Sema/ptrauth.c | 126 llvm/docs/PointerAuth.md | 3 + 30 files changed, 1315 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h create mode 100644 clang/test/Modules/ptrauth-include-from-darwin.m create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 11cbdca7a268fc3..49a3934d9d082fc 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4157,6 +4158,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 000..87b8f244a2e4653 --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,548 @@ +Pointer Authentication +==
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha labeled https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -303,6 +303,10 @@ bool Module::directlyUses(const Module *Requested) {
if (!Requested->Parent && Requested->Name == "_Builtin_stddef_max_align_t")
return true;
+ // Anyone is allowed to use our builtin ptrauth.h and its accompanying
module.
+ if (!Requested->Parent && Requested->Name == "ptrauth")
ahmedbougacha wrote:
Unfortunately this is needed, to match the (compiler-interface-defining)
`ptrauth.h` header file we vend. (specifically this is to allow usage of
`ptrauth.h` from `no_undeclared_interfaces` modules, see ed84df008f609.
https://github.com/llvm/llvm-project/pull/65996
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is b
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is b
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is b
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is b
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is b
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is b
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. ahmedbougacha wrote: I read "ultimately" here as "boiled down to the important part" (so, e.g., allowing value-preserving conversions between the auth/sign); we could remove the word altogether though! As for "expected", I think that's in opposition to the next sentence, about the unexpected cases where it doesn't actually do that ;) https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is b
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha updated https://github.com/llvm/llvm-project/pull/65996: >From fccf0643bd7812301819f5c7fce30d81c6e86a80 Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Wed, 16 Aug 2023 09:17:12 -0700 Subject: [PATCH] [AArch64][PAC] Support and document ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, in addition to these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 265 ++ clang/include/clang/Basic/Builtins.def| 8 + clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 ++ clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/Module.cpp| 4 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 + clang/lib/Driver/ToolChains/Clang.cpp | 5 + clang/lib/Frontend/CompilerInvocation.cpp | 13 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 167 +++ clang/lib/Sema/SemaChecking.cpp | 182 clang/test/CodeGen/ptrauth-intrinsics.c | 73 + .../module.modulemap | 8 + .../ptrauth-include-from-darwin/ptrauth.h | 1 + .../ptrauth-include-from-darwin/stddef.h | 1 + .../Modules/ptrauth-include-from-darwin.m | 6 + clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 +++ clang/test/Sema/ptrauth.c | 126 + llvm/docs/PointerAuth.md | 3 + 30 files changed, 1032 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h create mode 100644 clang/test/Modules/ptrauth-include-from-darwin.m create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 11cbdca7a268fc3..49a3934d9d082fc 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4157,6 +4158,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 000..96bcf2cd5fc824b --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -303,6 +303,10 @@ bool Module::directlyUses(const Module *Requested) {
if (!Requested->Parent && Requested->Name == "_Builtin_stddef_max_align_t")
return true;
+ // Anyone is allowed to use our builtin ptrauth.h and its accompanying
module.
+ if (!Requested->Parent && Requested->Name == "ptrauth")
ahmedbougacha wrote:
It’s needed in this patch because this patch introduces the `ptrauth.h` header
file, which wouldn’t be usable from modules without this change.
If you have an alternative fix I’m open to suggestions.
https://github.com/llvm/llvm-project/pull/65996
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r318545 - [CodeGen] Compute the objc EH vtable address point using inbounds GEP.
Author: ab
Date: Fri Nov 17 11:46:47 2017
New Revision: 318545
URL: http://llvm.org/viewvc/llvm-project?rev=318545&view=rev
Log:
[CodeGen] Compute the objc EH vtable address point using inbounds GEP.
The object is provided by the objc runtime and is never visible in the
module itself, but even so, the address point we compute points into it,
and "+16" is guaranteed not to overflow.
This matches the c++ vtable IRGen.
Note that I'm not entirely convinced the 'i8*' type is correct here: at
the IR level, we're accessing memory that's outside the global object.
But we don't control the allocation, so it's not obviously wrong either.
But either way, this is only in a global initializer, so I don't think
it's going to be mucked with. Filed PR35352 to discuss that.
Modified:
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/test/CodeGenObjC/attr-exception.m
Modified: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCMac.cpp?rev=318545&r1=318544&r2=318545&view=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp Fri Nov 17 11:46:47 2017
@@ -7558,8 +7558,9 @@ CGObjCNonFragileABIMac::GetInterfaceEHTy
llvm::Value *VTableIdx = llvm::ConstantInt::get(CGM.Int32Ty, 2);
ConstantInitBuilder builder(CGM);
auto values = builder.beginStruct(ObjCTypes.EHTypeTy);
- values.add(llvm::ConstantExpr::getGetElementPtr(VTableGV->getValueType(),
- VTableGV, VTableIdx));
+ values.add(
+llvm::ConstantExpr::getInBoundsGetElementPtr(VTableGV->getValueType(),
+ VTableGV, VTableIdx));
values.add(GetClassName(ClassName));
values.add(GetClassGlobal(ID, /*metaclass*/ false, NotForDefinition));
Modified: cfe/trunk/test/CodeGenObjC/attr-exception.m
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/attr-exception.m?rev=318545&r1=318544&r2=318545&view=diff
==
--- cfe/trunk/test/CodeGenObjC/attr-exception.m (original)
+++ cfe/trunk/test/CodeGenObjC/attr-exception.m Fri Nov 17 11:46:47 2017
@@ -13,8 +13,8 @@ __attribute__((objc_exception))
@implementation A
@end
-// CHECK: @"OBJC_EHTYPE_$_A" = global {{%.*}} { i8** getelementptr (i8*, i8**
@objc_ehtype_vtable, i32 2)
-// CHECK-HIDDEN: @"OBJC_EHTYPE_$_A" = hidden global {{%.*}} { i8**
getelementptr (i8*, i8** @objc_ehtype_vtable, i32 2)
+// CHECK: @"OBJC_EHTYPE_$_A" = global {{%.*}} { i8** getelementptr inbounds
(i8*, i8** @objc_ehtype_vtable, i32 2)
+// CHECK-HIDDEN: @"OBJC_EHTYPE_$_A" = hidden global {{%.*}} { i8**
getelementptr inbounds (i8*, i8** @objc_ehtype_vtable, i32 2)
__attribute__((objc_exception))
__attribute__((visibility("default")))
@@ -23,5 +23,5 @@ __attribute__((visibility("default")))
@implementation B
@end
-// CHECK: @"OBJC_EHTYPE_$_B" = global {{%.*}} { i8** getelementptr (i8*, i8**
@objc_ehtype_vtable, i32 2)
-// CHECK-HIDDEN: @"OBJC_EHTYPE_$_B" = global {{%.*}} { i8** getelementptr
(i8*, i8** @objc_ehtype_vtable, i32 2)
+// CHECK: @"OBJC_EHTYPE_$_B" = global {{%.*}} { i8** getelementptr inbounds
(i8*, i8** @objc_ehtype_vtable, i32 2)
+// CHECK-HIDDEN: @"OBJC_EHTYPE_$_B" = global {{%.*}} { i8** getelementptr
inbounds (i8*, i8** @objc_ehtype_vtable, i32 2)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r289839 - [Driver] Bump default x86 cpu to Penryn when targeting macosx10.12+.
Author: ab
Date: Thu Dec 15 12:14:27 2016
New Revision: 289839
URL: http://llvm.org/viewvc/llvm-project?rev=289839&view=rev
Log:
[Driver] Bump default x86 cpu to Penryn when targeting macosx10.12+.
10.12 dropped support for all pre-Penryn Macs.
Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/clang-translation.c
Modified: cfe/trunk/lib/Driver/Tools.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=289839&r1=289838&r2=289839&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Thu Dec 15 12:14:27 2016
@@ -2015,6 +2015,11 @@ static const char *getX86TargetCPU(const
if (Triple.isOSDarwin()) {
if (Triple.getArchName() == "x86_64h")
return "core-avx2";
+// macosx10.12 drops support for all pre-Penryn Macs.
+// Simulators can still run on 10.11 though, like Xcode.
+if (Triple.isMacOSX() && !Triple.isOSVersionLT(10, 12))
+ return "penryn";
+// The oldest x86_64 Macs have core2/Merom; the oldest x86 Macs have Yonah.
return Is64Bit ? "core2" : "yonah";
}
Modified: cfe/trunk/test/Driver/clang-translation.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/clang-translation.c?rev=289839&r1=289838&r2=289839&view=diff
==
--- cfe/trunk/test/Driver/clang-translation.c (original)
+++ cfe/trunk/test/Driver/clang-translation.c Thu Dec 15 12:14:27 2016
@@ -11,19 +11,36 @@
// I386: "hidden"
// I386: "-o"
// I386: clang-translation
+
// RUN: %clang -target i386-apple-darwin9 -### -S %s -o %t.s 2>&1 | \
// RUN: FileCheck -check-prefix=YONAH %s
+// RUN: %clang -target i386-apple-macosx10.11 -### -S %s -o %t.s 2>&1 | \
+// RUN: FileCheck -check-prefix=YONAH %s
// YONAH: "-target-cpu"
// YONAH: "yonah"
+
// RUN: %clang -target x86_64-apple-darwin9 -### -S %s -o %t.s 2>&1 | \
// RUN: FileCheck -check-prefix=CORE2 %s
+// RUN: %clang -target x86_64-apple-macosx10.11 -### -S %s -o %t.s 2>&1 | \
+// RUN: FileCheck -check-prefix=CORE2 %s
// CORE2: "-target-cpu"
// CORE2: "core2"
+
// RUN: %clang -target x86_64h-apple-darwin -### -S %s -o %t.s 2>&1 | \
// RUN: FileCheck -check-prefix=AVX2 %s
+// RUN: %clang -target x86_64h-apple-macosx10.12 -### -S %s -o %t.s 2>&1 | \
+// RUN: FileCheck -check-prefix=AVX2 %s
// AVX2: "-target-cpu"
// AVX2: "core-avx2"
+// RUN: %clang -target i386-apple-macosx10.12 -### -S %s -o %t.s 2>&1 | \
+// RUN: FileCheck -check-prefix=PENRYN %s
+// RUN: %clang -target x86_64-apple-macosx10.12 -### -S %s -o %t.s 2>&1 | \
+// RUN: FileCheck -check-prefix=PENRYN %s
+// PENRYN: "-target-cpu"
+// PENRYN: "penryn"
+
+
// RUN: %clang -target x86_64-apple-darwin10 -### -S %s -arch armv7 2>&1 | \
// RUN: FileCheck -check-prefix=ARMV7_DEFAULT %s
// ARMV7_DEFAULT: clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r280839 - Resubmit "Add a test for clang-tidy using the clang-cl driver."
Hi Zachary,
This test has been failing on some OS X machines, e.g.:
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/21470/consoleFull#19036563798254eaf0-7326-4999-85b0-388101f2d404
My hypothesis is that the %s path ('/Users/...') is somehow
interpreted as a '/U' by the clang-cl driver, causing the cryptic
'Error while processing /Users/.../clang-cl-driver.cpp' error (as the
test succeeds when run from other paths: /tmp/, /Volumes/).
Does that make sense? Any suggestions on how to fix?
Thanks!
-Ahmed
On Wed, Sep 7, 2016 at 11:28 AM, Zachary Turner via cfe-commits
wrote:
> Author: zturner
> Date: Wed Sep 7 13:28:42 2016
> New Revision: 280839
>
> URL: http://llvm.org/viewvc/llvm-project?rev=280839&view=rev
> Log:
> Resubmit "Add a test for clang-tidy using the clang-cl driver."
>
> This was originally reverted because the patch on the clang
> tooling side was reverted. That patch is being resubmitted,
> so this patch is resubmitted as well.
>
> Added:
> clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp
>
> Added: clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp?rev=280839&view=auto
> ==
> --- clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp (added)
> +++ clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp Wed Sep 7
> 13:28:42 2016
> @@ -0,0 +1,17 @@
> +// RUN: clang-tidy -checks=-*,modernize-use-nullptr %s -- --driver-mode=cl
> /DTEST1 /DFOO=foo /DBAR=bar | FileCheck
> -implicit-check-not="{{warning|error}}:" %s
> +int *a = 0;
> +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
> +#ifdef TEST1
> +int *b = 0;
> +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
> +#endif
> +#define foo 1
> +#define bar 1
> +#if FOO
> +int *c = 0;
> +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
> +#endif
> +#if BAR
> +int *d = 0;
> +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
> +#endif
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r280839 - Resubmit "Add a test for clang-tidy using the clang-cl driver."
On Thu, Sep 8, 2016 at 9:38 AM, Zachary Turner wrote:
> What happens if you put the %s in quotes?
Same error
-Ahmed
>
> On Thu, Sep 8, 2016 at 9:32 AM Ahmed Bougacha
> wrote:
>>
>> Hi Zachary,
>>
>> This test has been failing on some OS X machines, e.g.:
>>
>> http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/21470/consoleFull#19036563798254eaf0-7326-4999-85b0-388101f2d404
>>
>> My hypothesis is that the %s path ('/Users/...') is somehow
>> interpreted as a '/U' by the clang-cl driver, causing the cryptic
>> 'Error while processing /Users/.../clang-cl-driver.cpp' error (as the
>> test succeeds when run from other paths: /tmp/, /Volumes/).
>> Does that make sense? Any suggestions on how to fix?
>>
>> Thanks!
>> -Ahmed
>>
>>
>> On Wed, Sep 7, 2016 at 11:28 AM, Zachary Turner via cfe-commits
>> wrote:
>> > Author: zturner
>> > Date: Wed Sep 7 13:28:42 2016
>> > New Revision: 280839
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=280839&view=rev
>> > Log:
>> > Resubmit "Add a test for clang-tidy using the clang-cl driver."
>> >
>> > This was originally reverted because the patch on the clang
>> > tooling side was reverted. That patch is being resubmitted,
>> > so this patch is resubmitted as well.
>> >
>> > Added:
>> > clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp
>> >
>> > Added: clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp?rev=280839&view=auto
>> >
>> > ==
>> > --- clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp (added)
>> > +++ clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp Wed Sep
>> > 7 13:28:42 2016
>> > @@ -0,0 +1,17 @@
>> > +// RUN: clang-tidy -checks=-*,modernize-use-nullptr %s --
>> > --driver-mode=cl /DTEST1 /DFOO=foo /DBAR=bar | FileCheck
>> > -implicit-check-not="{{warning|error}}:" %s
>> > +int *a = 0;
>> > +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
>> > +#ifdef TEST1
>> > +int *b = 0;
>> > +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
>> > +#endif
>> > +#define foo 1
>> > +#define bar 1
>> > +#if FOO
>> > +int *c = 0;
>> > +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
>> > +#endif
>> > +#if BAR
>> > +int *d = 0;
>> > +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
>> > +#endif
>> >
>> >
>> > ___
>> > cfe-commits mailing list
>> > cfe-commits@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] r280975 - Revert "Resubmit "Add a test for clang-tidy using the clang-cl driver.""
Author: ab
Date: Thu Sep 8 13:02:14 2016
New Revision: 280975
URL: http://llvm.org/viewvc/llvm-project?rev=280975&view=rev
Log:
Revert "Resubmit "Add a test for clang-tidy using the clang-cl driver.""
This reverts commit r280839.
It's problematic on OS X, where the '/Users/...' paths are interpreted
as '/U' options.
Investigation ongoing in http://llvm.org/PR30328.
Removed:
clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp
Removed: clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp?rev=280974&view=auto
==
--- clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp (removed)
@@ -1,17 +0,0 @@
-// RUN: clang-tidy -checks=-*,modernize-use-nullptr %s -- --driver-mode=cl
/DTEST1 /DFOO=foo /DBAR=bar | FileCheck
-implicit-check-not="{{warning|error}}:" %s
-int *a = 0;
-// CHECK: :[[@LINE-1]]:10: warning: use nullptr
-#ifdef TEST1
-int *b = 0;
-// CHECK: :[[@LINE-1]]:10: warning: use nullptr
-#endif
-#define foo 1
-#define bar 1
-#if FOO
-int *c = 0;
-// CHECK: :[[@LINE-1]]:10: warning: use nullptr
-#endif
-#if BAR
-int *d = 0;
-// CHECK: :[[@LINE-1]]:10: warning: use nullptr
-#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r280839 - Resubmit "Add a test for clang-tidy using the clang-cl driver."
On Thu, Sep 8, 2016 at 9:52 AM, Zachary Turner wrote:
> I don't have access to an OSX machine to test on, but if you do, is there
> any way you could test this command line manually using a path that starts
> with /U and see if you can reproduce it?
(Did you mean to include a command line?)
I tried both the test and a trivial clang-check command line with /U
and non-/U paths (with -###; I couldn't find a clang-cl equivalent to '-v'):
clang-check "/Volumes/.../clang-cl-driver.cpp" -- --driver-mode=cl -###
clang-check "/Users/.../clang-cl-driver.cpp" -- --driver-mode=cl -###
and I do get an error for the /U path:
warning: argument unused during compilation: '-U sers/.../clang-cl-driver.cpp'
error: unable to handle compilation, expected exactly one compiler job in ''
Error while processing /Users/.../clang-cl-driver.cpp.
In any case, I reverted the test in r280975, let's continue this
discussion in PR30328. Let me know if you have any ideas; I'll
experiment locally later.
-Ahmed
> On Thu, Sep 8, 2016 at 9:45 AM Ahmed Bougacha
> wrote:
>>
>> On Thu, Sep 8, 2016 at 9:38 AM, Zachary Turner wrote:
>> > What happens if you put the %s in quotes?
>>
>> Same error
>>
>> -Ahmed
>>
>> >
>> > On Thu, Sep 8, 2016 at 9:32 AM Ahmed Bougacha
>> > wrote:
>> >>
>> >> Hi Zachary,
>> >>
>> >> This test has been failing on some OS X machines, e.g.:
>> >>
>> >>
>> >> http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/21470/consoleFull#19036563798254eaf0-7326-4999-85b0-388101f2d404
>> >>
>> >> My hypothesis is that the %s path ('/Users/...') is somehow
>> >> interpreted as a '/U' by the clang-cl driver, causing the cryptic
>> >> 'Error while processing /Users/.../clang-cl-driver.cpp' error (as the
>> >> test succeeds when run from other paths: /tmp/, /Volumes/).
>> >> Does that make sense? Any suggestions on how to fix?
>> >>
>> >> Thanks!
>> >> -Ahmed
>> >>
>> >>
>> >> On Wed, Sep 7, 2016 at 11:28 AM, Zachary Turner via cfe-commits
>> >> wrote:
>> >> > Author: zturner
>> >> > Date: Wed Sep 7 13:28:42 2016
>> >> > New Revision: 280839
>> >> >
>> >> > URL: http://llvm.org/viewvc/llvm-project?rev=280839&view=rev
>> >> > Log:
>> >> > Resubmit "Add a test for clang-tidy using the clang-cl driver."
>> >> >
>> >> > This was originally reverted because the patch on the clang
>> >> > tooling side was reverted. That patch is being resubmitted,
>> >> > so this patch is resubmitted as well.
>> >> >
>> >> > Added:
>> >> > clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp
>> >> >
>> >> > Added: clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp
>> >> > URL:
>> >> >
>> >> > http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp?rev=280839&view=auto
>> >> >
>> >> >
>> >> > ==
>> >> > --- clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp
>> >> > (added)
>> >> > +++ clang-tools-extra/trunk/test/clang-tidy/clang-cl-driver.cpp Wed
>> >> > Sep
>> >> > 7 13:28:42 2016
>> >> > @@ -0,0 +1,17 @@
>> >> > +// RUN: clang-tidy -checks=-*,modernize-use-nullptr %s --
>> >> > --driver-mode=cl /DTEST1 /DFOO=foo /DBAR=bar | FileCheck
>> >> > -implicit-check-not="{{warning|error}}:" %s
>> >> > +int *a = 0;
>> >> > +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
>> >> > +#ifdef TEST1
>> >> > +int *b = 0;
>> >> > +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
>> >> > +#endif
>> >> > +#define foo 1
>> >> > +#define bar 1
>> >> > +#if FOO
>> >> > +int *c = 0;
>> >> > +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
>> >> > +#endif
>> >> > +#if BAR
>> >> > +int *d = 0;
>> >> > +// CHECK: :[[@LINE-1]]:10: warning: use nullptr
>> >> > +#endif
>> >> >
>> >> >
>> >> > ___
>> >> > cfe-commits mailing list
>> >> > cfe-commits@lists.llvm.org
>> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r301410 - [OPENMP] Move handling of threadprivate vars from the stack, NFC.
Hey Alexey,
This is causing asan errors, e.g.:
==4735==ERROR: AddressSanitizer: heap-buffer-overflow on
address 0x61f00e70 at pc 0x00010a8a7f4a bp 0x7fff5c57a390
sp 0x7fff5c57a388
READ of size 4 at 0x61f00e70 thread T0
#0 0x10a8a7f49 in
(anonymous namespace)::DSAStackTy::hasDSA(clang::ValueDecl*,
llvm::function_ref const&, llvm::function_ref const&, bool) SemaOpenMP.cpp:836
#1 0x10a8a4560
in clang::Sema::IsOpenMPCapturedDecl(clang::ValueDecl*) SemaOpenMP.cpp:1107
#2 0x10a575739 in
clang::Sema::tryCaptureVariable(clang::VarDecl*, clang::SourceLocation,
clang::Sema::TryCaptureKind, clang::SourceLocation, bool, clang::QualType&,
clang::QualType&, unsigned int const*) SemaExpr.cpp:14005
...
0x61f00e70 is located 16 bytes to the left of 3440-byte
region [0x61f00e80,0x61f01bf0) allocated by thread T0 here:
#0 0x116f036d2 in
wrap__Znwm (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x656d2)
#1 0x10a8a1642 in
clang::Sema::InitDataSharingAttributesStack() SemaOpenMP.cpp:914
#2 0x109fc8585 in
clang::Sema::Sema(clang::Preprocessor&, clang::ASTContext&,
clang::ASTConsumer&,
clang::TranslationUnitKind, clang::CodeCompleteConsumer*) Sema.cpp:125
...
SUMMARY: AddressSanitizer: heap-buffer-overflow SemaOpenMP.cpp:836
in (anonymous
namespace)::DSAStackTy::hasDSA(clang::ValueDecl*, llvm::function_ref const&, llvm::function_ref const&, bool)
http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan_check/3344/testReport/junit/Clang/OpenMP/atomic_codegen_cpp/
Can you have a look?
Thanks!
-Ahmed
On Wed, Apr 26, 2017 at 7:24 AM, Alexey Bataev via cfe-commits
wrote:
> Author: abataev
> Date: Wed Apr 26 09:24:21 2017
> New Revision: 301410
>
> URL: http://llvm.org/viewvc/llvm-project?rev=301410&view=rev
> Log:
> [OPENMP] Move handling of threadprivate vars from the stack, NFC.
>
> Threadprivate variables do no need to be handled in the Stack of all
> directives, moving it out for better performance and memory.
>
> Modified:
> cfe/trunk/lib/Sema/SemaOpenMP.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
> URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=301410&r1=301409&r2=301410&view=diff
>
==
> --- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Wed Apr 26 09:24:21 2017
> @@ -118,6 +118,7 @@ private:
>typedef SmallVector StackTy;
>
>/// \brief Stack of used declaration and their data-sharing attributes.
> + DeclSAMapTy Threadprivates;
>StackTy Stack;
>/// \brief true, if check for DSA must be from parent directive,
false, if
>/// from current directive.
> @@ -134,7 +135,7 @@ private:
>bool isOpenMPLocal(VarDecl *D, StackTy::reverse_iterator Iter);
>
> public:
> - explicit DSAStackTy(Sema &S) : Stack(1), SemaRef(S) {}
> + explicit DSAStackTy(Sema &S) : SemaRef(S) {}
>
>bool isClauseParsingMode() const { return ClauseKindMode !=
OMPC_unknown; }
>void setClauseParsingMode(OpenMPClauseKind K) { ClauseKindMode = K; }
> @@ -149,7 +150,7 @@ public:
>}
>
>void pop() {
> -assert(Stack.size() > 1 && "Data-sharing attributes stack is
empty!");
> +assert(!Stack.empty() && "Data-sharing attributes stack is empty!");
> Stack.pop_back();
>}
>
> @@ -229,11 +230,11 @@ public:
>
>/// \brief Returns currently analyzed directive.
>OpenMPDirectiveKind getCurrentDirective() const {
> -return Stack.back().Directive;
> +return Stack.empty() ? OMPD_unknown : Stack.back().Directive;
>}
>/// \brief Returns parent directive.
>OpenMPDirectiveKind getParentDirective() const {
> -if (Stack.size() > 2)
> +if (Stack.size() > 1)
>return Stack[Stack.size() - 2].Directive;
> return OMPD_unknown;
>}
> @@ -250,10 +251,10 @@ public:
>}
>
>DefaultDataSharingAttributes getDefaultDSA() const {
> -return Stack.back().DefaultAttr;
> +return Stack.empty() ? DSA_unspecified : Stack.back().DefaultAttr;
>}
>SourceLocation getDefaultDSALocation() const {
> -return Stack.back().DefaultAttrLoc;
> +return Stack.empty() ? SourceLocation() :
Stack.back().DefaultAttrLoc;
>}
>
>/// \brief Checks if the specified variable is a threadprivate.
> @@ -270,13 +271,13 @@ public:
>/// \brief Returns true, if parent region is ordered (has associated
>/// 'ordered' clause), false - otherwise.
>bool isParentOrderedRegion() const {
> -if (Stack.size() > 2)
> +if (Stack.size() > 1)
>return Stack[Stack.size() - 2].OrderedRegion.getInt();
> return false;
>}
>/// \brief Returns optional parameter for the ordered region.
>Expr *getParentOrderedRegionParam() const {
> -if (Stack.size() > 2)
> +if (Stack.size() > 1)
>return Stack[Stack.size() - 2].OrderedRegion.getPointer();
> return nullptr;
>}
> @@ -287,28 +288,32 @@ public:
>/// \brief Returns true, if parent region is
r302079 - [Driver] Update AArch64 testcase to match llvm r302078.
Author: ab
Date: Wed May 3 15:34:32 2017
New Revision: 302079
URL: http://llvm.org/viewvc/llvm-project?rev=302079&view=rev
Log:
[Driver] Update AArch64 testcase to match llvm r302078.
Modified:
cfe/trunk/test/Preprocessor/aarch64-target-features.c
Modified: cfe/trunk/test/Preprocessor/aarch64-target-features.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/aarch64-target-features.c?rev=302079&r1=302078&r2=302079&view=diff
==
--- cfe/trunk/test/Preprocessor/aarch64-target-features.c (original)
+++ cfe/trunk/test/Preprocessor/aarch64-target-features.c Wed May 3 15:34:32
2017
@@ -109,7 +109,7 @@
// CHECK-MCPU-THUNDERX2T99: "-cc1"{{.*}} "-triple" "aarch64{{.*}}"
"-target-feature" "+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
// RUN: %clang -target x86_64-apple-macosx -arch arm64 -### -c %s 2>&1 |
FileCheck --check-prefix=CHECK-ARCH-ARM64 %s
-// CHECK-ARCH-ARM64: "-target-cpu" "cyclone" "-target-feature" "+neon"
"-target-feature" "+crypto" "-target-feature" "+zcm" "-target-feature" "+zcz"
+// CHECK-ARCH-ARM64: "-target-cpu" "cyclone" "-target-feature" "+fp-armv8"
"-target-feature" "+neon" "-target-feature" "+crypto" "-target-feature" "+zcm"
"-target-feature" "+zcz"
// RUN: %clang -target aarch64 -march=armv8-a+fp+simd+crc+crypto -### -c %s
2>&1 | FileCheck -check-prefix=CHECK-MARCH-1 %s
// RUN: %clang -target aarch64
-march=armv8-a+nofp+nosimd+nocrc+nocrypto+fp+simd+crc+crypto -### -c %s 2>&1 |
FileCheck -check-prefix=CHECK-MARCH-1 %s
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r249205 - Don't nil check non-nil class receiver of AArch64 stret calls.
Author: ab
Date: Fri Oct 2 17:41:59 2015
New Revision: 249205
URL: http://llvm.org/viewvc/llvm-project?rev=249205&view=rev
Log:
Don't nil check non-nil class receiver of AArch64 stret calls.
I randomly came across this difference between AArch64 and other targets:
on the latter, we don't emit nil checks for known non-nil class method
calls thanks to r247350, but we still do for AArch64 stret calls.
They use different code paths, because those are special, as they go
through the regular msgSend, not the msgSend*_stret variants.
Modified:
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/test/CodeGenObjC/stret-1.m
Modified: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCMac.cpp?rev=249205&r1=249204&r2=249205&view=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp Fri Oct 2 17:41:59 2015
@@ -1931,7 +1931,7 @@ CGObjCCommonMac::EmitMessageSend(CodeGen
} else {
// arm64 uses objc_msgSend for stret methods and yet null receiver check
// must be made for it.
-if (!IsSuper && CGM.ReturnTypeUsesSRet(MSI.CallInfo))
+if (ReceiverCanBeNull && CGM.ReturnTypeUsesSRet(MSI.CallInfo))
nullReturn.init(CGF, Arg0);
Fn = (ObjCABI == 2) ? ObjCTypes.getSendFn2(IsSuper)
: ObjCTypes.getSendFn(IsSuper);
Modified: cfe/trunk/test/CodeGenObjC/stret-1.m
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/stret-1.m?rev=249205&r1=249204&r2=249205&view=diff
==
--- cfe/trunk/test/CodeGenObjC/stret-1.m (original)
+++ cfe/trunk/test/CodeGenObjC/stret-1.m Fri Oct 2 17:41:59 2015
@@ -1,8 +1,7 @@
-// RUN: %clang_cc1 -fblocks -triple arm64-apple-darwin %s -emit-llvm -o - |
FileCheck %s -check-prefix=CHECK-ARM64
+// RUN: %clang_cc1 -fblocks -triple arm64-apple-darwin %s -emit-llvm -o - |
FileCheck %s
// rdar://12416433
struct stret { int x[100]; };
-struct stret zero;
struct stret one = {{1}};
@interface Test @end
@@ -13,8 +12,12 @@ struct stret one = {{1}};
int main(int argc, const char **argv)
{
-struct stret st2 = one;
-if (argc) st2 = [(id)(argc&~255) method];
-}
+[(id)(argc&~255) method];
+// CHECK: call void bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to void
(%struct.stret*, i8*, i8*)*)(%struct.stret* sret [[T0:%[^,]+]]
+// CHECK: [[T0P:%.*]] = bitcast %struct.stret* [[T0]] to i8*
+// CHECK: call void @llvm.memset.p0i8.i64(i8* [[T0P]], i8 0, i64 400, i32
4, i1 false)
-// CHECK-ARM64: call void @llvm.memset.p0i8.i64(i8* [[T0:%.*]], i8 0, i64 400,
i32 4, i1 false)
+[Test method];
+// CHECK: call void bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to void
(%struct.stret*, i8*, i8*)*)(%struct.stret* sret [[T1:%[^,]+]]
+// CHECK-NOT: call void @llvm.memset.p0i8.i64(
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r249213 - [Headers][X86] Fix stream_load (movntdqa) to accept const*.
Author: ab
Date: Fri Oct 2 18:29:26 2015
New Revision: 249213
URL: http://llvm.org/viewvc/llvm-project?rev=249213&view=rev
Log:
[Headers][X86] Fix stream_load (movntdqa) to accept const*.
Per Intel intrinsics guide:
- _mm256_stream_load_si256 takes `__m256i const *'
- _mm_stream_load_si128 takes `__m128i *', for no good reason.
Let's accept const* for both.
Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Headers/avx2intrin.h
cfe/trunk/lib/Headers/smmintrin.h
cfe/trunk/test/CodeGen/avx2-builtins.c
cfe/trunk/test/CodeGen/sse41-builtins.c
Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=249213&r1=249212&r2=249213&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Fri Oct 2 18:29:26 2015
@@ -390,7 +390,7 @@ TARGET_BUILTIN(__builtin_ia32_roundsd, "
TARGET_BUILTIN(__builtin_ia32_roundpd, "V2dV2di", "", "sse4.1")
TARGET_BUILTIN(__builtin_ia32_dpps, "V4fV4fV4fIc", "", "sse4.1")
TARGET_BUILTIN(__builtin_ia32_dppd, "V2dV2dV2dIc", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_movntdqa, "V2LLiV2LLi*", "", "sse4.1")
+TARGET_BUILTIN(__builtin_ia32_movntdqa, "V2LLiV2LLiC*", "", "sse4.1")
TARGET_BUILTIN(__builtin_ia32_ptestz128, "iV2LLiV2LLi", "", "sse4.1")
TARGET_BUILTIN(__builtin_ia32_ptestc128, "iV2LLiV2LLi", "", "sse4.1")
TARGET_BUILTIN(__builtin_ia32_ptestnzc128, "iV2LLiV2LLi", "", "sse4.1")
@@ -594,7 +594,7 @@ TARGET_BUILTIN(__builtin_ia32_psrldi256,
TARGET_BUILTIN(__builtin_ia32_psrld256, "V8iV8iV4i", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_psrlqi256, "V4LLiV4LLii", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_psrlq256, "V4LLiV4LLiV2LLi", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_movntdqa256, "V4LLiV4LLi*", "", "avx2")
+TARGET_BUILTIN(__builtin_ia32_movntdqa256, "V4LLiV4LLiC*", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_permvarsi256, "V8iV8iV8i", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_permvarsf256, "V8fV8fV8f", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_permti256, "V4LLiV4LLiV4LLiIc", "", "avx2")
Modified: cfe/trunk/lib/Headers/avx2intrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx2intrin.h?rev=249213&r1=249212&r2=249213&view=diff
==
--- cfe/trunk/lib/Headers/avx2intrin.h (original)
+++ cfe/trunk/lib/Headers/avx2intrin.h Fri Oct 2 18:29:26 2015
@@ -754,9 +754,9 @@ _mm256_xor_si256(__m256i __a, __m256i __
}
static __inline__ __m256i __DEFAULT_FN_ATTRS
-_mm256_stream_load_si256(__m256i *__V)
+_mm256_stream_load_si256(__m256i const *__V)
{
- return (__m256i)__builtin_ia32_movntdqa256((__v4di *)__V);
+ return (__m256i)__builtin_ia32_movntdqa256((const __v4di *)__V);
}
static __inline__ __m128 __DEFAULT_FN_ATTRS
Modified: cfe/trunk/lib/Headers/smmintrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/smmintrin.h?rev=249213&r1=249212&r2=249213&view=diff
==
--- cfe/trunk/lib/Headers/smmintrin.h (original)
+++ cfe/trunk/lib/Headers/smmintrin.h Fri Oct 2 18:29:26 2015
@@ -151,9 +151,9 @@ _mm_mul_epi32 (__m128i __V1, __m128i __V
/* SSE4 Streaming Load Hint Instruction. */
static __inline__ __m128i __DEFAULT_FN_ATTRS
-_mm_stream_load_si128 (__m128i *__V)
+_mm_stream_load_si128 (__m128i const *__V)
{
- return (__m128i) __builtin_ia32_movntdqa ((__v2di *) __V);
+ return (__m128i) __builtin_ia32_movntdqa ((const __v2di *) __V);
}
/* SSE4 Packed Integer Min/Max Instructions. */
Modified: cfe/trunk/test/CodeGen/avx2-builtins.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx2-builtins.c?rev=249213&r1=249212&r2=249213&view=diff
==
--- cfe/trunk/test/CodeGen/avx2-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx2-builtins.c Fri Oct 2 18:29:26 2015
@@ -728,7 +728,7 @@ __m256i test_mm256_unpacklo_epi64(__m256
return _mm256_unpacklo_epi64(a, b);
}
-__m256i test_mm256_stream_load_si256(__m256i *a) {
+__m256i test_mm256_stream_load_si256(__m256i const *a) {
// CHECK: @llvm.x86.avx2.movntdqa
// CHECK-ASM: vmovntdqa (%rdi), %ymm{{.*}}
return _mm256_stream_load_si256(a);
Modified: cfe/trunk/test/CodeGen/sse41-builtins.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse41-builtins.c?rev=249213&r1=249212&r2=249213&view=diff
==
--- cfe/trunk/test/CodeGen/sse41-builtins.c (original)
+++ cfe/trunk/test/CodeGen/sse41-builtins.c Fri Oct 2 18:29:26 2015
@@ -385,7 +385,7 @@ __m128 test_mm_round_ss(__m128 x, __m128
return _mm_round_ss(x, y, 2);
}
-__m128i test_mm_stream_load_si128(__m128i *a) {
+__m128i test_mm_
Re: [PATCH] D7297: [clang][Headers] _mm_stream_load_si128 should accept const arguments.
ab closed this revision. ab added a comment. Stumbled upon this while looking for the intel guide! Fixed in r249213. http://reviews.llvm.org/D7297 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D12143: [X86][AVX2] Replace avx2.pbroadcast / avx2.vbroadcast intrinsics usage in avx2intrin.h with __builtin_shufflevector
ab added a comment. Heh, this is http://reviews.llvm.org/D10556, no? :P Repository: rL LLVM http://reviews.llvm.org/D12143 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r245605 - [Headers][X86] Use __builtin_shufflevector in AVX2 broadcasts.
Author: ab
Date: Thu Aug 20 15:27:21 2015
New Revision: 245605
URL: http://llvm.org/viewvc/llvm-project?rev=245605&view=rev
Log:
[Headers][X86] Use __builtin_shufflevector in AVX2 broadcasts.
This lets us optimize them better. We agreed to remove the intrinsics,
instead of combining them later, as, at -O0, we generate the expected
instructions. Plus, it's a nice cleanup.
Differential Revision: http://reviews.llvm.org/D10556
Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Headers/avx2intrin.h
cfe/trunk/test/CodeGen/avx2-builtins.c
Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=245605&r1=245604&r2=245605&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Thu Aug 20 15:27:21 2015
@@ -590,17 +590,6 @@ TARGET_BUILTIN(__builtin_ia32_psrld256,
TARGET_BUILTIN(__builtin_ia32_psrlqi256, "V4LLiV4LLii", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_psrlq256, "V4LLiV4LLiV2LLi", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_movntdqa256, "V4LLiV4LLi*", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_vbroadcastss_ps, "V4fV4f", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_vbroadcastss_ps256, "V8fV4f", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_vbroadcastsd_pd256, "V4dV2d", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_pbroadcastb256, "V32cV16c", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_pbroadcastw256, "V16sV8s", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_pbroadcastd256, "V8iV4i", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_pbroadcastq256, "V4LLiV2LLi", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_pbroadcastb128, "V16cV16c", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_pbroadcastw128, "V8sV8s", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_pbroadcastd128, "V4iV4i", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_pbroadcastq128, "V2LLiV2LLi", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_permvarsi256, "V8iV8iV8i", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_permvarsf256, "V8fV8fV8f", "", "avx2")
TARGET_BUILTIN(__builtin_ia32_permti256, "V4LLiV4LLiV4LLiIc", "", "avx2")
Modified: cfe/trunk/lib/Headers/avx2intrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx2intrin.h?rev=245605&r1=245604&r2=245605&view=diff
==
--- cfe/trunk/lib/Headers/avx2intrin.h (original)
+++ cfe/trunk/lib/Headers/avx2intrin.h Thu Aug 20 15:27:21 2015
@@ -760,7 +760,7 @@ _mm256_stream_load_si256(__m256i *__V)
static __inline__ __m128 __DEFAULT_FN_ATTRS
_mm_broadcastss_ps(__m128 __X)
{
- return (__m128)__builtin_ia32_vbroadcastss_ps((__v4sf)__X);
+ return (__m128)__builtin_shufflevector((__v4sf)__X, (__v4sf)__X, 0, 0, 0, 0);
}
static __inline__ __m128d __DEFAULT_FN_ATTRS
@@ -772,13 +772,13 @@ _mm_broadcastsd_pd(__m128d __a)
static __inline__ __m256 __DEFAULT_FN_ATTRS
_mm256_broadcastss_ps(__m128 __X)
{
- return (__m256)__builtin_ia32_vbroadcastss_ps256((__v4sf)__X);
+ return (__m256)__builtin_shufflevector((__v4sf)__X, (__v4sf)__X, 0, 0, 0, 0,
0, 0, 0, 0);
}
static __inline__ __m256d __DEFAULT_FN_ATTRS
_mm256_broadcastsd_pd(__m128d __X)
{
- return (__m256d)__builtin_ia32_vbroadcastsd_pd256((__v2df)__X);
+ return (__m256d)__builtin_shufflevector((__v2df)__X, (__v2df)__X, 0, 0, 0,
0);
}
static __inline__ __m256i __DEFAULT_FN_ATTRS
@@ -812,50 +812,50 @@ _mm256_broadcastsi128_si256(__m128i __X)
static __inline__ __m256i __DEFAULT_FN_ATTRS
_mm256_broadcastb_epi8(__m128i __X)
{
- return (__m256i)__builtin_ia32_pbroadcastb256((__v16qi)__X);
+ return (__m256i)__builtin_shufflevector((__v16qi)__X, (__v16qi)__X, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0);
}
static __inline__ __m256i __DEFAULT_FN_ATTRS
_mm256_broadcastw_epi16(__m128i __X)
{
- return (__m256i)__builtin_ia32_pbroadcastw256((__v8hi)__X);
+ return (__m256i)__builtin_shufflevector((__v8hi)__X, (__v8hi)__X, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
}
static __inline__ __m256i __DEFAULT_FN_ATTRS
_mm256_broadcastd_epi32(__m128i __X)
{
- return (__m256i)__builtin_ia32_pbroadcastd256((__v4si)__X);
+ return (__m256i)__builtin_shufflevector((__v4si)__X, (__v4si)__X, 0, 0, 0,
0, 0, 0, 0, 0);
}
static __inline__ __m256i __DEFAULT_FN_ATTRS
_mm256_broadcastq_epi64(__m128i __X)
{
- return (__m256i)__builtin_ia32_pbroadcastq256(__X);
+ return (__m256i)__builtin_shufflevector(__X, __X, 0, 0, 0, 0);
}
static __inline__ __m128i __DEFAULT_FN_ATTRS
_mm_broadcastb_epi8(__m128i __X)
{
- return (__m128i)__builtin_ia32_pbroadcastb128((__v16qi)__X);
+ return (__m128i)__builtin_shufflevector((__v16qi)__X, (__v16qi)__X, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
}
static __inline__ __m128i __DEFAULT_FN_ATTRS
_mm_broadcastw_epi16(__m128i __
Re: [PATCH] D10556: [Headers][X86] Replace avx2.pbroadcast intrinsics with native IR.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL245605: [Headers][X86] Use __builtin_shufflevector in AVX2
broadcasts. (authored by ab).
Changed prior to commit:
http://reviews.llvm.org/D10556?vs=27973&id=32729#toc
Repository:
rL LLVM
http://reviews.llvm.org/D10556
Files:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Headers/avx2intrin.h
cfe/trunk/test/CodeGen/avx2-builtins.c
Index: cfe/trunk/test/CodeGen/avx2-builtins.c
===
--- cfe/trunk/test/CodeGen/avx2-builtins.c
+++ cfe/trunk/test/CodeGen/avx2-builtins.c
@@ -607,7 +607,9 @@
}
__m128 test_mm_broadcastss_ps(__m128 a) {
- // CHECK: @llvm.x86.avx2.vbroadcast.ss.ps
+ // CHECK-LABEL: test_mm_broadcastss_ps
+ // CHECK-NOT: @llvm.x86.avx2.vbroadcast.ss.ps
+ // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x i32> zeroinitializer
return _mm_broadcastss_ps(a);
}
@@ -617,12 +619,16 @@
}
__m256 test_mm256_broadcastss_ps(__m128 a) {
- // CHECK: @llvm.x86.avx2.vbroadcast.ss.ps.256
+ // CHECK-LABEL: test_mm256_broadcastss_ps
+ // CHECK-NOT: @llvm.x86.avx2.vbroadcast.ss.ps.256
+ // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> zeroinitializer
return _mm256_broadcastss_ps(a);
}
__m256d test_mm256_broadcastsd_pd(__m128d a) {
- // check: @llvm.x86.avx2.vbroadcast.sd.pd.256
+ // CHECK-LABEL: test_mm256_broadcastsd_pd
+ // CHECK-NOT: @llvm.x86.avx2.vbroadcast.sd.pd.256
+ // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <4 x i32> zeroinitializer
return _mm256_broadcastsd_pd(a);
}
@@ -646,42 +652,58 @@
}
__m256i test_mm256_broadcastb_epi8(__m128i a) {
- // CHECK: @llvm.x86.avx2.pbroadcastb.256
+ // CHECK-LABEL: test_mm256_broadcastb_epi8
+ // CHECK-NOT: @llvm.x86.avx2.pbroadcastb.256
+ // CHECK: shufflevector <16 x i8> %{{.*}}, <16 x i8> %{{.*}}, <32 x i32> zeroinitializer
return _mm256_broadcastb_epi8(a);
}
__m256i test_mm256_broadcastw_epi16(__m128i a) {
- // CHECK: @llvm.x86.avx2.pbroadcastw.256
+ // CHECK-LABEL: test_mm256_broadcastw_epi16
+ // CHECK-NOT: @llvm.x86.avx2.pbroadcastw.256
+ // CHECK: shufflevector <8 x i16> %{{.*}}, <8 x i16> %{{.*}}, <16 x i32> zeroinitializer
return _mm256_broadcastw_epi16(a);
}
__m256i test_mm256_broadcastd_epi32(__m128i a) {
- // CHECK: @llvm.x86.avx2.pbroadcastd.256
+ // CHECK-LABEL: test_mm256_broadcastd_epi32
+ // CHECK-NOT: @llvm.x86.avx2.pbroadcastd.256
+ // CHECK: shufflevector <4 x i32> %{{.*}}, <4 x i32> %{{.*}}, <8 x i32> zeroinitializer
return _mm256_broadcastd_epi32(a);
}
__m256i test_mm256_broadcastq_epi64(__m128i a) {
- // CHECK: @llvm.x86.avx2.pbroadcastq.256
+ // CHECK-LABEL: test_mm256_broadcastq_epi64
+ // CHECK-NOT: @llvm.x86.avx2.pbroadcastq.256
+ // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> zeroinitializer
return _mm256_broadcastq_epi64(a);
}
__m128i test_mm_broadcastb_epi8(__m128i a) {
- // CHECK: @llvm.x86.avx2.pbroadcastb.128
+ // CHECK-LABEL: test_mm_broadcastb_epi8
+ // CHECK-NOT: @llvm.x86.avx2.pbroadcastb.128
+ // CHECK: shufflevector <16 x i8> %{{.*}}, <16 x i8> %{{.*}}, <16 x i32> zeroinitializer
return _mm_broadcastb_epi8(a);
}
__m128i test_mm_broadcastw_epi16(__m128i a) {
- // CHECK: @llvm.x86.avx2.pbroadcastw.128
+ // CHECK-LABEL: test_mm_broadcastw_epi16
+ // CHECK-NOT: @llvm.x86.avx2.pbroadcastw.128
+ // CHECK: shufflevector <8 x i16> %{{.*}}, <8 x i16> %{{.*}}, <8 x i32> zeroinitializer
return _mm_broadcastw_epi16(a);
}
__m128i test_mm_broadcastd_epi32(__m128i a) {
- // CHECK: @llvm.x86.avx2.pbroadcastd.128
+ // CHECK-LABEL: test_mm_broadcastd_epi32
+ // CHECK-NOT: @llvm.x86.avx2.pbroadcastd.128
+ // CHECK: shufflevector <4 x i32> %{{.*}}, <4 x i32> %{{.*}}, <4 x i32> zeroinitializer
return _mm_broadcastd_epi32(a);
}
__m128i test_mm_broadcastq_epi64(__m128i a) {
- // CHECK: @llvm.x86.avx2.pbroadcastq.128
+ // CHECK-LABEL: test_mm_broadcastq_epi64
+ // CHECK-NOT: @llvm.x86.avx2.pbroadcastq.128
+ // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <2 x i32> zeroinitializer
return _mm_broadcastq_epi64(a);
}
Index: cfe/trunk/lib/Headers/avx2intrin.h
===
--- cfe/trunk/lib/Headers/avx2intrin.h
+++ cfe/trunk/lib/Headers/avx2intrin.h
@@ -760,7 +760,7 @@
static __inline__ __m128 __DEFAULT_FN_ATTRS
_mm_broadcastss_ps(__m128 __X)
{
- return (__m128)__builtin_ia32_vbroadcastss_ps((__v4sf)__X);
+ return (__m128)__builtin_shufflevector((__v4sf)__X, (__v4sf)__X, 0, 0, 0, 0);
}
static __inline__ __m128d __DEFAULT_FN_ATTRS
@@ -772,13 +772,13 @@
static __inline__ __m256 __DEFAULT_FN_ATTRS
_mm256_broadcastss_ps(__m128 __X)
{
- return (__m256)__builtin_ia32_vbroadcastss_ps256((__v4sf)__X);
+ return (__m256)__builtin_shufflevector((__v4sf)__X, (__v4sf)__X, 0, 0, 0, 0, 0, 0, 0, 0);
[PATCH] D12212: [Headers][X86] Add -O0 assembly tests for intrinsics.
ab created this revision.
ab added reviewers: spatel, RKSimon.
ab added subscribers: cfe-commits, chandlerc, silvas, qcolombet.
We agreed in D10555 that, as long as we don't affect -O0 codegen too much, it's
OK to use native constructs rather than intrinsics. Let's test that, starting
with AVX2 here. I'll add others if people are fine with the idea, or have
objections to the mixed testing.
http://reviews.llvm.org/D12212
Files:
avx2-builtins-codegen.c
Index: avx2-builtins-codegen.c
===
--- avx2-builtins-codegen.c
+++ avx2-builtins-codegen.c
@@ -1,178 +1,215 @@
// RUN: %clang_cc1 %s -O0 -triple=x86_64-apple-darwin -target-feature +avx2 -emit-llvm -o - -Werror | FileCheck %s
+// RUN: %clang_cc1 %s -O0 -triple=x86_64-apple-darwin -target-feature +avx2 -S -o - -Werror | FileCheck %s --check-prefix=CHECK-ASM
// Don't include mm_malloc.h, it's system specific.
#define __MM_MALLOC_H
#include
__m256i test_mm256_mpsadbw_epu8(__m256i x, __m256i y) {
// CHECK: @llvm.x86.avx2.mpsadbw({{.*}}, {{.*}}, i8 3)
+ // CHECK-ASM: vmpsadbw $3, %ymm{{.*}}
return _mm256_mpsadbw_epu8(x, y, 3);
}
__m256i test_mm256_sad_epu8(__m256i x, __m256i y) {
// CHECK: @llvm.x86.avx2.psad.bw
+ // CHECK-ASM: vpsadbw %ymm{{.*}}
return _mm256_sad_epu8(x, y);
}
__m256i test_mm256_abs_epi8(__m256i a) {
// CHECK: @llvm.x86.avx2.pabs.b
+ // CHECK-ASM: vpabsb %ymm{{.*}}
return _mm256_abs_epi8(a);
}
__m256i test_mm256_abs_epi16(__m256i a) {
// CHECK: @llvm.x86.avx2.pabs.w
+ // CHECK-ASM: vpabsw %ymm{{.*}}
return _mm256_abs_epi16(a);
}
__m256i test_mm256_abs_epi32(__m256i a) {
// CHECK: @llvm.x86.avx2.pabs.d
+ // CHECK-ASM: vpabsd %ymm{{.*}}
return _mm256_abs_epi32(a);
}
__m256i test_mm256_packs_epi16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packsswb
+ // CHECK-ASM: vpacksswb %ymm{{.*}}
return _mm256_packs_epi16(a, b);
}
__m256i test_mm256_packs_epi32(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packssdw
+ // CHECK-ASM: vpackssdw %ymm{{.*}}
return _mm256_packs_epi32(a, b);
}
__m256i test_mm256_packs_epu16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packuswb
+ // CHECK-ASM: vpackuswb %ymm{{.*}}
return _mm256_packus_epi16(a, b);
}
__m256i test_mm256_packs_epu32(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packusdw
+ // CHECK-ASM: vpackusdw %ymm{{.*}}
return _mm256_packus_epi32(a, b);
}
__m256i test_mm256_add_epi8(__m256i a, __m256i b) {
// CHECK: add <32 x i8>
+ // CHECK-ASM: vpaddb %ymm{{.*}}
return _mm256_add_epi8(a, b);
}
__m256i test_mm256_add_epi16(__m256i a, __m256i b) {
// CHECK: add <16 x i16>
+ // CHECK-ASM: vpaddw %ymm{{.*}}
return _mm256_add_epi16(a, b);
}
__m256i test_mm256_add_epi32(__m256i a, __m256i b) {
// CHECK: add <8 x i32>
+ // CHECK-ASM: vpaddd %ymm{{.*}}
return _mm256_add_epi32(a, b);
}
__m256i test_mm256_add_epi64(__m256i a, __m256i b) {
// CHECK: add <4 x i64>
+ // CHECK-ASM: vpaddq {{.*}}, %ymm{{.*}}
return _mm256_add_epi64(a, b);
}
__m256i test_mm256_adds_epi8(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.padds.b
+ // CHECK-ASM: vpaddsb %ymm{{.*}}
return _mm256_adds_epi8(a, b);
}
__m256i test_mm256_adds_epi16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.padds.w
+ // CHECK-ASM: vpaddsw %ymm{{.*}}
return _mm256_adds_epi16(a, b);
}
__m256i test_mm256_adds_epu8(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.paddus.b
+ // CHECK-ASM: vpaddusb %ymm{{.*}}
return _mm256_adds_epu8(a, b);
}
__m256i test_mm256_adds_epu16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.paddus.w
+ // CHECK-ASM: vpaddusw %ymm{{.*}}
return _mm256_adds_epu16(a, b);
}
__m256i test_mm256_alignr_epi8(__m256i a, __m256i b) {
// CHECK: shufflevector <32 x i8> %{{.*}}, <32 x i8> %{{.*}}, <32 x i32>
+ // CHECK-ASM: vpalignr $2, %ymm{{.*}}
return _mm256_alignr_epi8(a, b, 2);
}
__m256i test2_mm256_alignr_epi8(__m256i a, __m256i b) {
// CHECK: shufflevector <32 x i8> %{{.*}}, <32 x i8> zeroinitializer, <32 x i32>
+ // CHECK-ASM: vpsrldq $1, %ymm{{.*}}
return _mm256_alignr_epi8(a, b, 17);
}
__m256i test_mm256_sub_epi8(__m256i a, __m256i b) {
// CHECK: sub <32 x i8>
+ // CHECK-ASM: vpsubb %ymm{{.*}}
return _mm256_sub_epi8(a, b);
}
__m256i test_mm256_sub_epi16(__m256i a, __m256i b) {
// CHECK: sub <16 x i16>
+ // CHECK-ASM: vpsubw %ymm{{.*}}
return _mm256_sub_epi16(a, b);
}
__m256i test_mm256_sub_epi32(__m256i a, __m256i b) {
// CHECK: sub <8 x i32>
+ // CHECK-ASM: vpsubd %ymm{{.*}}
return _mm256_sub_epi32(a, b);
}
__m256i test_mm256_sub_epi64(__m256i a, __m256i b) {
// CHECK: sub <4 x i64>
+ // CHECK-ASM: vpsubq {{.*}}, %ymm{{.*}}
return _mm256_sub_epi64(a, b);
}
__m256i test_mm256_subs_epi8(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.psubs.b
+ // CHECK-ASM: vpsubsb %ymm{{.*}}
return _mm256_subs_ep
Re: [PATCH] D12240: [AArch64] Define the macro __ARM_FP16_ARGS
ab added a subscriber: ab. ab accepted this revision. ab added a reviewer: ab. ab added a comment. This revision is now accepted and ready to land. LGTM, thanks! http://reviews.llvm.org/D12240 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r245761 - [ARM NEON] Factor out FP-prototype checking. NFC.
Author: ab
Date: Fri Aug 21 18:24:18 2015
New Revision: 245761
URL: http://llvm.org/viewvc/llvm-project?rev=245761&view=rev
Log:
[ARM NEON] Factor out FP-prototype checking. NFC.
Modified:
cfe/trunk/utils/TableGen/NeonEmitter.cpp
Modified: cfe/trunk/utils/TableGen/NeonEmitter.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/NeonEmitter.cpp?rev=245761&r1=245760&r2=245761&view=diff
==
--- cfe/trunk/utils/TableGen/NeonEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/NeonEmitter.cpp Fri Aug 21 18:24:18 2015
@@ -993,6 +993,10 @@ std::string Intrinsic::getInstTypeCode(T
return S;
}
+static bool isFloatingPointProtoModifier(char Mod) {
+ return Mod == 'F' || Mod == 'f';
+}
+
std::string Intrinsic::getBuiltinTypeStr() {
ClassKind LocalCK = getClassKind(true);
std::string S;
@@ -1014,7 +1018,7 @@ std::string Intrinsic::getBuiltinTypeStr
if (!RetT.isScalar() && !RetT.isSigned())
RetT.makeSigned();
-bool ForcedVectorFloatingType = Proto[0] == 'F' || Proto[0] == 'f';
+bool ForcedVectorFloatingType = isFloatingPointProtoModifier(Proto[0]);
if (LocalCK == ClassB && !RetT.isScalar() && !ForcedVectorFloatingType)
// Cast to vector of 8-bit elements.
RetT.makeInteger(8, true);
@@ -1027,7 +1031,7 @@ std::string Intrinsic::getBuiltinTypeStr
if (T.isPoly())
T.makeInteger(T.getElementSizeInBits(), false);
-bool ForcedFloatingType = Proto[I + 1] == 'F' || Proto[I + 1] == 'f';
+bool ForcedFloatingType = isFloatingPointProtoModifier(Proto[I + 1]);
if (LocalCK == ClassB && !T.isScalar() && !ForcedFloatingType)
T.makeInteger(8, true);
// Halves always get converted to 8-bit elements.
@@ -1364,7 +1368,7 @@ void Intrinsic::emitBodyAsBuiltinCall()
// Extra constant integer to hold type class enum for this function, e.g. s8
if (getClassKind(true) == ClassB) {
Type ThisTy = getReturnType();
-if (Proto[0] == 'v' || Proto[0] == 'f' || Proto[0] == 'F')
+if (Proto[0] == 'v' || isFloatingPointProtoModifier(Proto[0]))
ThisTy = getParamType(0);
if (ThisTy.isPointer())
ThisTy = getParamType(1);
@@ -2022,8 +2026,8 @@ void NeonEmitter::genOverloadTypeCheckCo
uint64_t Mask = 0ULL;
Type Ty = Def->getReturnType();
-if (Def->getProto()[0] == 'v' || Def->getProto()[0] == 'f' ||
-Def->getProto()[0] == 'F')
+if (Def->getProto()[0] == 'v' ||
+isFloatingPointProtoModifier(Def->getProto()[0]))
Ty = Def->getParamType(0);
if (Ty.isPointer())
Ty = Def->getParamType(1);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r245763 - [ARM NEON] Use the common naming scheme for vcvt f16 builtins. NFC.
Author: ab
Date: Fri Aug 21 18:34:20 2015
New Revision: 245763
URL: http://llvm.org/viewvc/llvm-project?rev=245763&view=rev
Log:
[ARM NEON] Use the common naming scheme for vcvt f16 builtins. NFC.
We had "vcvt_f16" and "VCVT_HIGH_F16": for other FP types, this naming
is used for intrinsics with integer overloads. The FP->FP conversions,
on the other hand, use the full "vcvt_f32_f64" name instead.
Use the same naming convention for the f16<->f32 conversions.
While there, reorder the definitions a little bit.
Modified:
cfe/trunk/include/clang/Basic/arm_neon.td
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/utils/TableGen/NeonEmitter.cpp
Modified: cfe/trunk/include/clang/Basic/arm_neon.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/arm_neon.td?rev=245763&r1=245762&r2=245763&view=diff
==
--- cfe/trunk/include/clang/Basic/arm_neon.td (original)
+++ cfe/trunk/include/clang/Basic/arm_neon.td Fri Aug 21 18:34:20 2015
@@ -414,7 +414,7 @@ def OP_XTN : Op<(call "vcombine", $
def OP_SQXTUN : Op<(call "vcombine", (cast $p0, "U", $p0),
(call "vqmovun", $p1))>;
def OP_QXTN : Op<(call "vcombine", $p0, (call "vqmovn", $p1))>;
-def OP_VCVT_NA_HI_F16 : Op<(call "vcombine", $p0, (call "vcvt_f16", $p1))>;
+def OP_VCVT_NA_HI_F16 : Op<(call "vcombine", $p0, (call "vcvt_f16_f32", $p1))>;
def OP_VCVT_NA_HI_F32 : Op<(call "vcombine", $p0, (call "vcvt_f32_f64", $p1))>;
def OP_VCVT_EX_HI_F32 : Op<(call "vcvt_f32_f16", (call "vget_high", $p0))>;
def OP_VCVT_EX_HI_F64 : Op<(call "vcvt_f64_f32", (call "vget_high", $p0))>;
@@ -687,16 +687,19 @@ def VGET_LOW : NoTestOpInst<"vget_low",
// E.3.22 Converting vectors
+
+def VCVT_F16_F32 : SInst<"vcvt_f16_f32", "hk", "f">;
+def VCVT_F32_F16 : SInst<"vcvt_f32_f16", "fd", "h">;
+
def VCVT_S32 : SInst<"vcvt_s32", "xd", "fQf">;
def VCVT_U32 : SInst<"vcvt_u32", "ud", "fQf">;
-def VCVT_F16 : SInst<"vcvt_f16", "hk", "f">;
def VCVT_F32 : SInst<"vcvt_f32", "fd", "iUiQiQUi">;
-def VCVT_F32_F16 : SInst<"vcvt_f32_f16", "fd", "h">;
let isVCVT_N = 1 in {
def VCVT_N_S32 : SInst<"vcvt_n_s32", "xdi", "fQf">;
def VCVT_N_U32 : SInst<"vcvt_n_u32", "udi", "fQf">;
def VCVT_N_F32 : SInst<"vcvt_n_f32", "fdi", "iUiQiQUi">;
}
+
def VMOVN: IInst<"vmovn", "hk", "silUsUiUl">;
def VMOVL: SInst<"vmovl", "wd", "csiUcUsUi">;
def VQMOVN : SInst<"vqmovn", "hk", "silUsUiUl">;
@@ -923,6 +926,9 @@ def USQADD : SInst<"vsqadd", "ddd", "UcU
// Reciprocal/Sqrt
def FRECPS : IInst<"vrecps", "ddd", "dQd">;
def FRSQRTS : IInst<"vrsqrts", "ddd", "dQd">;
+def FRECPE : SInst<"vrecpe", "dd", "dQd">;
+def FRSQRTE : SInst<"vrsqrte", "dd", "dQd">;
+def FSQRT : SInst<"vsqrt", "dd", "fdQfQd">;
// bitwise reverse
@@ -942,20 +948,21 @@ def QXTN2 : SOpInst<"vqmovn_high", "qhk"
// Converting vectors
-def VCVT_HIGH_F16 : SOpInst<"vcvt_high_f16", "qhj", "f", OP_VCVT_NA_HI_F16>;
-def VCVT_HIGH_F32_F16 : SOpInst<"vcvt_high_f32", "wk", "h", OP_VCVT_EX_HI_F32>;
+
def VCVT_F32_F64 : SInst<"vcvt_f32_f64", "md", "Qd">;
-def VCVT_HIGH_F32_F64 : SOpInst<"vcvt_high_f32", "qfj", "d",
OP_VCVT_NA_HI_F32>;
def VCVT_F64_F32 : SInst<"vcvt_f64_f32", "wd", "f">;
+
+def VCVT_S64 : SInst<"vcvt_s64", "xd", "dQd">;
+def VCVT_U64 : SInst<"vcvt_u64", "ud", "dQd">;
def VCVT_F64 : SInst<"vcvt_f64", "Fd", "lUlQlQUl">;
+
+def VCVT_HIGH_F16_f32 : SOpInst<"vcvt_high_f16", "qhj", "f",
OP_VCVT_NA_HI_F16>;
+def VCVT_HIGH_F32_F16 : SOpInst<"vcvt_high_f32", "wk", "h", OP_VCVT_EX_HI_F32>;
+def VCVT_HIGH_F32_F64 : SOpInst<"vcvt_high_f32", "qfj", "d",
OP_VCVT_NA_HI_F32>;
def VCVT_HIGH_F64_F32 : SOpInst<"vcvt_high_f64", "wj", "f", OP_VCVT_EX_HI_F64>;
-def VCVTX_F32_F64 : SInst<"vcvtx_f32", "fj", "d">;
+
+def VCVTX_F32_F64 : SInst<"vcvtx_f32", "fj", "d">;
def VCVTX_HIGH_F32_F64 : SOpInst<"vcvtx_high_f32", "qfj", "d", OP_VCVTX_HI>;
-def VCVT_S64 : SInst<"vcvt_s64", "xd", "dQd">;
-def VCVT_U64 : SInst<"vcvt_u64", "ud", "dQd">;
-def FRECPE : SInst<"vrecpe", "dd", "dQd">;
-def FRSQRTE : SInst<"vrsqrte", "dd", "dQd">;
-def FSQRT : SInst<"vsqrt", "dd", "fdQfQd">;
// Comparison
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=245763&r1=245762&r2=245763&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Fri Aug 21 18:34:20 2015
@@ -2102,7 +2102,7 @@ static NeonIntrinsicInfo ARMSIMDIntrinsi
r245778 - [ARM NEON] Remove special-case for f16 vcvt handling. NFCI.
Author: ab
Date: Fri Aug 21 20:30:13 2015
New Revision: 245778
URL: http://llvm.org/viewvc/llvm-project?rev=245778&view=rev
Log:
[ARM NEON] Remove special-case for f16 vcvt handling. NFCI.
We can use the 'H' typespec modifier to use 128-bit vectors directly
in the only two users of this special-case: the vcvt f16 intrinsics.
This also lets us use more meaningful prototype modifiers.
Modified:
cfe/trunk/include/clang/Basic/arm_neon.td
cfe/trunk/utils/TableGen/NeonEmitter.cpp
Modified: cfe/trunk/include/clang/Basic/arm_neon.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/arm_neon.td?rev=245778&r1=245777&r2=245778&view=diff
==
--- cfe/trunk/include/clang/Basic/arm_neon.td (original)
+++ cfe/trunk/include/clang/Basic/arm_neon.td Fri Aug 21 20:30:13 2015
@@ -688,8 +688,8 @@ def VGET_LOW : NoTestOpInst<"vget_low",
// E.3.22 Converting vectors
-def VCVT_F16_F32 : SInst<"vcvt_f16_f32", "hk", "f">;
-def VCVT_F32_F16 : SInst<"vcvt_f32_f16", "fd", "h">;
+def VCVT_F16_F32 : SInst<"vcvt_f16_f32", "md", "Hf">;
+def VCVT_F32_F16 : SInst<"vcvt_f32_f16", "wd", "h">;
def VCVT_S32 : SInst<"vcvt_s32", "xd", "fQf">;
def VCVT_U32 : SInst<"vcvt_u32", "ud", "fQf">;
@@ -956,7 +956,7 @@ def VCVT_S64 : SInst<"vcvt_s64", "xd",
def VCVT_U64 : SInst<"vcvt_u64", "ud", "dQd">;
def VCVT_F64 : SInst<"vcvt_f64", "Fd", "lUlQlQUl">;
-def VCVT_HIGH_F16_f32 : SOpInst<"vcvt_high_f16", "qhj", "f",
OP_VCVT_NA_HI_F16>;
+def VCVT_HIGH_F16_F32 : SOpInst<"vcvt_high_f16", "hmj", "Hf",
OP_VCVT_NA_HI_F16>;
def VCVT_HIGH_F32_F16 : SOpInst<"vcvt_high_f32", "wk", "h", OP_VCVT_EX_HI_F32>;
def VCVT_HIGH_F32_F64 : SOpInst<"vcvt_high_f32", "qfj", "d",
OP_VCVT_NA_HI_F32>;
def VCVT_HIGH_F64_F32 : SOpInst<"vcvt_high_f64", "wj", "f", OP_VCVT_EX_HI_F64>;
Modified: cfe/trunk/utils/TableGen/NeonEmitter.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/NeonEmitter.cpp?rev=245778&r1=245777&r2=245778&view=diff
==
--- cfe/trunk/utils/TableGen/NeonEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/NeonEmitter.cpp Fri Aug 21 20:30:13 2015
@@ -837,10 +837,6 @@ void Type::applyModifier(char Mod) {
Float = true;
break;
case 'f':
-// Special case - if we're half-precision, a floating
-// point argument needs to be 128-bits (double size).
-if (isHalf())
- Bitwidth = 128;
Float = true;
ElementBitwidth = 32;
break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r245901 - [ARM NEON] Add missing AArch64 vget tests.
Author: ab
Date: Mon Aug 24 18:34:25 2015
New Revision: 245901
URL: http://llvm.org/viewvc/llvm-project?rev=245901&view=rev
Log:
[ARM NEON] Add missing AArch64 vget tests.
Added:
cfe/trunk/test/CodeGen/aarch64-neon-vget.c
- copied, changed from r245893, cfe/trunk/test/CodeGen/arm64_vget.c
Removed:
cfe/trunk/test/CodeGen/arm64_vget.c
Copied: cfe/trunk/test/CodeGen/aarch64-neon-vget.c (from r245893,
cfe/trunk/test/CodeGen/arm64_vget.c)
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aarch64-neon-vget.c?p2=cfe/trunk/test/CodeGen/aarch64-neon-vget.c&p1=cfe/trunk/test/CodeGen/arm64_vget.c&r1=245893&r2=245901&rev=245901&view=diff
==
--- cfe/trunk/test/CodeGen/arm64_vget.c (original)
+++ cfe/trunk/test/CodeGen/aarch64-neon-vget.c Mon Aug 24 18:34:25 2015
@@ -1,13 +1,348 @@
-// RUN: %clang_cc1 -O1 -triple arm64-apple-ios7 -target-feature +neon
-ffreestanding -S -o - -emit-llvm %s | FileCheck %s
-// Test ARM64 SIMD vget intrinsics
+// REQUIRES: aarch64-registered-target
+// RUN: %clang_cc1 -triple arm64-apple-darwin -target-feature +neon \
+// RUN: -ffp-contract=fast -S -O3 -o - %s | FileCheck %s
#include
-float64_t test_vget_lane_f64(float64x1_t a1) {
- // CHECK: test_vget_lane_f64
- // why isn't 1 allowed as second argument?
- return vget_lane_f64(a1, 0);
- // CHECK: extractelement {{.*}} i32 0
- // CHECK-NEXT: ret
+uint8_t test_vget_lane_u8(uint8x8_t a) {
+ // CHECK-LABEL: test_vget_lane_u8:
+ // CHECK-NEXT: umov.b w0, v0[7]
+ // CHECK-NEXT: ret
+ return vget_lane_u8(a, 7);
}
+uint16_t test_vget_lane_u16(uint16x4_t a) {
+ // CHECK-LABEL: test_vget_lane_u16:
+ // CHECK-NEXT: umov.h w0, v0[3]
+ // CHECK-NEXT: ret
+ return vget_lane_u16(a, 3);
+}
+
+uint32_t test_vget_lane_u32(uint32x2_t a) {
+ // CHECK-LABEL: test_vget_lane_u32:
+ // CHECK-NEXT: mov.s w0, v0[1]
+ // CHECK-NEXT: ret
+ return vget_lane_u32(a, 1);
+}
+
+int8_t test_vget_lane_s8(int8x8_t a) {
+ // CHECK-LABEL: test_vget_lane_s8:
+ // CHECK-NEXT: umov.b w0, v0[7]
+ // CHECK-NEXT: ret
+ return vget_lane_s8(a, 7);
+}
+
+int16_t test_vget_lane_s16(int16x4_t a) {
+ // CHECK-LABEL: test_vget_lane_s16:
+ // CHECK-NEXT: umov.h w0, v0[3]
+ // CHECK-NEXT: ret
+ return vget_lane_s16(a, 3);
+}
+
+int32_t test_vget_lane_s32(int32x2_t a) {
+ // CHECK-LABEL: test_vget_lane_s32:
+ // CHECK-NEXT: mov.s w0, v0[1]
+ // CHECK-NEXT: ret
+ return vget_lane_s32(a, 1);
+}
+
+poly8_t test_vget_lane_p8(poly8x8_t a) {
+ // CHECK-LABEL: test_vget_lane_p8:
+ // CHECK-NEXT: umov.b w0, v0[7]
+ // CHECK-NEXT: ret
+ return vget_lane_p8(a, 7);
+}
+
+poly16_t test_vget_lane_p16(poly16x4_t a) {
+ // CHECK-LABEL: test_vget_lane_p16:
+ // CHECK-NEXT: umov.h w0, v0[3]
+ // CHECK-NEXT: ret
+ return vget_lane_p16(a, 3);
+}
+
+float32_t test_vget_lane_f32(float32x2_t a) {
+ // CHECK-LABEL: test_vget_lane_f32:
+ // CHECK-NEXT: mov s0, v0[1]
+ // CHECK-NEXT: ret
+ return vget_lane_f32(a, 1);
+}
+
+float32_t test_vget_lane_f16(float16x4_t a) {
+ // CHECK-LABEL: test_vget_lane_f16:
+ // CHECK-NEXT: umov.h w8, v0[1]
+ // CHECK-NEXT: fmov s0, w8
+ // CHECK-NEXT: fcvt s0, h0
+ // CHECK-NEXT: ret
+ return vget_lane_f16(a, 1);
+}
+
+uint8_t test_vgetq_lane_u8(uint8x16_t a) {
+ // CHECK-LABEL: test_vgetq_lane_u8:
+ // CHECK-NEXT: umov.b w0, v0[15]
+ // CHECK-NEXT: ret
+ return vgetq_lane_u8(a, 15);
+}
+
+uint16_t test_vgetq_lane_u16(uint16x8_t a) {
+ // CHECK-LABEL: test_vgetq_lane_u16:
+ // CHECK-NEXT: umov.h w0, v0[7]
+ // CHECK-NEXT: ret
+ return vgetq_lane_u16(a, 7);
+}
+
+uint32_t test_vgetq_lane_u32(uint32x4_t a) {
+ // CHECK-LABEL: test_vgetq_lane_u32:
+ // CHECK-NEXT: mov.s w0, v0[3]
+ // CHECK-NEXT: ret
+ return vgetq_lane_u32(a, 3);
+}
+
+int8_t test_vgetq_lane_s8(int8x16_t a) {
+ // CHECK-LABEL: test_vgetq_lane_s8:
+ // CHECK-NEXT: umov.b w0, v0[15]
+ // CHECK-NEXT: ret
+ return vgetq_lane_s8(a, 15);
+}
+
+int16_t test_vgetq_lane_s16(int16x8_t a) {
+ // CHECK-LABEL: test_vgetq_lane_s16:
+ // CHECK-NEXT: umov.h w0, v0[7]
+ // CHECK-NEXT: ret
+ return vgetq_lane_s16(a, 7);
+}
+
+int32_t test_vgetq_lane_s32(int32x4_t a) {
+ // CHECK-LABEL: test_vgetq_lane_s32:
+ // CHECK-NEXT: mov.s w0, v0[3]
+ // CHECK-NEXT: ret
+ return vgetq_lane_s32(a, 3);
+}
+
+poly8_t test_vgetq_lane_p8(poly8x16_t a) {
+ // CHECK-LABEL: test_vgetq_lane_p8:
+ // CHECK-NEXT: umov.b w0, v0[15]
+ // CHECK-NEXT: ret
+ return vgetq_lane_p8(a, 15);
+}
+
+poly16_t test_vgetq_lane_p16(poly16x8_t a) {
+ // CHECK-LABEL: test_vgetq_lane_p16:
+ // CHECK-NEXT: umov.h w0, v0[7]
+ // CHECK-NEXT: ret
+ return vgetq_lane_p16(a, 7);
+}
+
+float32_t test_vgetq_lane_f32(float32x4_t a) {
+ // CHECK-LABEL: test_vgetq_lane_f32:
+ // CHECK-NEXT: mov s0, v0[3]
+ // CHECK-NEXT: ret
+ return vgetq_lane_f32(a, 3);
+}
+
+float32_t test_vgetq_lane_f16(float16x8_t a) {
+ // CHECK-LABEL: test_vgetq_lane_f16:
r245904 - [ARM NEON] Replace redundant code with a new GetFloatNeonType. NFC.
Author: ab
Date: Mon Aug 24 18:41:31 2015
New Revision: 245904
URL: http://llvm.org/viewvc/llvm-project?rev=245904&view=rev
Log:
[ARM NEON] Replace redundant code with a new GetFloatNeonType. NFC.
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=245904&r1=245903&r2=245904&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Mon Aug 24 18:41:31 2015
@@ -1917,6 +1917,19 @@ static llvm::VectorType *GetNeonType(Cod
llvm_unreachable("Unknown vector element type!");
}
+static llvm::VectorType *GetFloatNeonType(CodeGenFunction *CGF,
+ NeonTypeFlags IntTypeFlags) {
+ int IsQuad = IntTypeFlags.isQuad();
+ switch (IntTypeFlags.getEltType()) {
+ case NeonTypeFlags::Int32:
+return llvm::VectorType::get(CGF->FloatTy, (2 << IsQuad));
+ case NeonTypeFlags::Int64:
+return llvm::VectorType::get(CGF->DoubleTy, (1 << IsQuad));
+ default:
+llvm_unreachable("Type can't be converted to floating-point!");
+ }
+}
+
Value *CodeGenFunction::EmitNeonSplat(Value *V, Constant *C) {
unsigned nElts = cast(V->getType())->getNumElements();
Value* SV = llvm::ConstantVector::getSplat(nElts, C);
@@ -2817,13 +2830,7 @@ Value *CodeGenFunction::EmitCommonNeonBu
case NEON::BI__builtin_neon_vcvt_n_f64_v:
case NEON::BI__builtin_neon_vcvtq_n_f32_v:
case NEON::BI__builtin_neon_vcvtq_n_f64_v: {
-bool Double =
- (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *FloatTy =
-GetNeonType(this, NeonTypeFlags(Double ? NeonTypeFlags::Float64
- : NeonTypeFlags::Float32,
-false, Quad));
-llvm::Type *Tys[2] = { FloatTy, Ty };
+llvm::Type *Tys[2] = { GetFloatNeonType(this, Type), Ty };
Int = Usgn ? LLVMIntrinsic : AltLLVMIntrinsic;
Function *F = CGM.getIntrinsic(Int, Tys);
return EmitNeonCall(F, Ops, "vcvt_n");
@@ -2836,13 +2843,7 @@ Value *CodeGenFunction::EmitCommonNeonBu
case NEON::BI__builtin_neon_vcvtq_n_u32_v:
case NEON::BI__builtin_neon_vcvtq_n_s64_v:
case NEON::BI__builtin_neon_vcvtq_n_u64_v: {
-bool Double =
- (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *FloatTy =
-GetNeonType(this, NeonTypeFlags(Double ? NeonTypeFlags::Float64
- : NeonTypeFlags::Float32,
-false, Quad));
-llvm::Type *Tys[2] = { Ty, FloatTy };
+llvm::Type *Tys[2] = { Ty, GetFloatNeonType(this, Type) };
Function *F = CGM.getIntrinsic(LLVMIntrinsic, Tys);
return EmitNeonCall(F, Ops, "vcvt_n");
}
@@ -2854,13 +2855,7 @@ Value *CodeGenFunction::EmitCommonNeonBu
case NEON::BI__builtin_neon_vcvtq_u32_v:
case NEON::BI__builtin_neon_vcvtq_s64_v:
case NEON::BI__builtin_neon_vcvtq_u64_v: {
-bool Double =
- (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *FloatTy =
-GetNeonType(this, NeonTypeFlags(Double ? NeonTypeFlags::Float64
- : NeonTypeFlags::Float32,
-false, Quad));
-Ops[0] = Builder.CreateBitCast(Ops[0], FloatTy);
+Ops[0] = Builder.CreateBitCast(Ops[0], GetFloatNeonType(this, Type));
return Usgn ? Builder.CreateFPToUI(Ops[0], Ty, "vcvt")
: Builder.CreateFPToSI(Ops[0], Ty, "vcvt");
}
@@ -2896,13 +2891,7 @@ Value *CodeGenFunction::EmitCommonNeonBu
case NEON::BI__builtin_neon_vcvtmq_s64_v:
case NEON::BI__builtin_neon_vcvtmq_u32_v:
case NEON::BI__builtin_neon_vcvtmq_u64_v: {
-bool Double =
- (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *InTy =
- GetNeonType(this,
- NeonTypeFlags(Double ? NeonTypeFlags::Float64
-: NeonTypeFlags::Float32, false, Quad));
-llvm::Type *Tys[2] = { Ty, InTy };
+llvm::Type *Tys[2] = { Ty, GetFloatNeonType(this, Type) };
return EmitNeonCall(CGM.getIntrinsic(LLVMIntrinsic, Tys), Ops, NameHint);
}
case NEON::BI__builtin_neon_vext_v:
@@ -5174,13 +5163,7 @@ Value *CodeGenFunction::EmitAArch64Built
case NEON::BI__builtin_neon_vcvtq_u32_v:
case NEON::BI__builtin_neon_vcvtq_s64_v:
case NEON::BI__builtin_neon_vcvtq_u64_v: {
-bool Double =
- (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *InTy =
- GetNeonType(this,
- NeonTypeFlags(Double ? NeonTypeFlags::Float64
-: NeonTypeFlags::Float32, false, quad));
-Ops[0] = Builder.CreateBitCast(Ops[0], InTy);
+Ops[0] = Builder.CreateBitCast(Ops[0], GetFloatNeonType(this, Type));
if (usgn)
return Builder.CreateFPToUI(Ops[0], Ty
r245906 - [ARM NEON] Use CGF cached Types instead of llvm::Type::get. NFC.
Author: ab
Date: Mon Aug 24 18:47:29 2015
New Revision: 245906
URL: http://llvm.org/viewvc/llvm-project?rev=245906&view=rev
Log:
[ARM NEON] Use CGF cached Types instead of llvm::Type::get. NFC.
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=245906&r1=245905&r2=245906&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Mon Aug 24 18:47:29 2015
@@ -4472,7 +4472,7 @@ Value *CodeGenFunction::EmitAArch64Built
}
case NEON::BI__builtin_neon_vpaddd_f64: {
llvm::Type *Ty =
- llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 2);
+ llvm::VectorType::get(DoubleTy, 2);
Value *Vec = EmitScalarExpr(E->getArg(0));
// The vector is v2f64, so make sure it's bitcast to that.
Vec = Builder.CreateBitCast(Vec, Ty, "v2f64");
@@ -4485,7 +4485,7 @@ Value *CodeGenFunction::EmitAArch64Built
}
case NEON::BI__builtin_neon_vpadds_f32: {
llvm::Type *Ty =
- llvm::VectorType::get(llvm::Type::getFloatTy(getLLVMContext()), 2);
+ llvm::VectorType::get(FloatTy, 2);
Value *Vec = EmitScalarExpr(E->getArg(0));
// The vector is v2f32, so make sure it's bitcast to that.
Vec = Builder.CreateBitCast(Vec, Ty, "v2f32");
@@ -4640,7 +4640,7 @@ Value *CodeGenFunction::EmitAArch64Built
case NEON::BI__builtin_neon_vsetq_lane_f64:
// The vector type needs a cast for the v2f64 variant.
Ops[1] = Builder.CreateBitCast(Ops[1],
-llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 2));
+llvm::VectorType::get(DoubleTy, 2));
Ops.push_back(EmitScalarExpr(E->getArg(2)));
return Builder.CreateInsertElement(Ops[1], Ops[0], Ops[2], "vset_lane");
@@ -4671,7 +4671,7 @@ Value *CodeGenFunction::EmitAArch64Built
"vget_lane");
case NEON::BI__builtin_neon_vdups_lane_f32:
Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getFloatTy(getLLVMContext()), 2));
+llvm::VectorType::get(FloatTy, 2));
return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
"vdups_lane");
case NEON::BI__builtin_neon_vgetq_lane_i32:
@@ -4686,7 +4686,7 @@ Value *CodeGenFunction::EmitAArch64Built
"vget_lane");
case NEON::BI__builtin_neon_vdupd_lane_f64:
Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 1));
+llvm::VectorType::get(DoubleTy, 1));
return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
"vdupd_lane");
case NEON::BI__builtin_neon_vgetq_lane_i64:
@@ -4696,24 +4696,24 @@ Value *CodeGenFunction::EmitAArch64Built
"vgetq_lane");
case NEON::BI__builtin_neon_vget_lane_f32:
Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getFloatTy(getLLVMContext()), 2));
+llvm::VectorType::get(FloatTy, 2));
return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
"vget_lane");
case NEON::BI__builtin_neon_vget_lane_f64:
Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 1));
+llvm::VectorType::get(DoubleTy, 1));
return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
"vget_lane");
case NEON::BI__builtin_neon_vgetq_lane_f32:
case NEON::BI__builtin_neon_vdups_laneq_f32:
Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getFloatTy(getLLVMContext()), 4));
+llvm::VectorType::get(FloatTy, 4));
return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
"vgetq_lane");
case NEON::BI__builtin_neon_vgetq_lane_f64:
case NEON::BI__builtin_neon_vdupd_laneq_f64:
Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 2));
+llvm::VectorType::get(DoubleTy, 2));
return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
"vgetq_lane");
case NEON::BI__builtin_neon_vaddd_s64:
@@ -5052,15 +5052,13 @@ Value *CodeGenFunction::EmitAArch64Built
Int = Intrinsic::aarch64_neon_fmaxnm;
return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vmaxnm");
case NEON::BI__builtin_neon_vrecpss_f32: {
-llvm::Type *f32Type = llvm::Type::getFloatTy(getLLVMContext());
Ops.push_back(EmitScalarExpr(E->getArg(1)));
-return EmitNeonCall(CGM.getIntrinsic(Intrinsic::aarch64_ne
r245915 - [ARM NEON] Remove the old AArch64 vset_lane tests. NFC.
Author: ab
Date: Mon Aug 24 20:00:05 2015
New Revision: 245915
URL: http://llvm.org/viewvc/llvm-project?rev=245915&view=rev
Log:
[ARM NEON] Remove the old AArch64 vset_lane tests. NFC.
They are now properly tested, since r245901.
Removed:
cfe/trunk/test/CodeGen/arm64_vset_lane.c
Removed: cfe/trunk/test/CodeGen/arm64_vset_lane.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm64_vset_lane.c?rev=245914&view=auto
==
--- cfe/trunk/test/CodeGen/arm64_vset_lane.c (original)
+++ cfe/trunk/test/CodeGen/arm64_vset_lane.c (removed)
@@ -1,33 +0,0 @@
-// RUN: %clang_cc1 -O1 -triple arm64-apple-ios7 -target-feature +neon
-ffreestanding -S -o - -emit-llvm %s | FileCheck %s
-// Test ARM64 SIMD set lane intrinsics INCOMPLETE
-
-#include
-
-float16x4_t test_vset_lane_f16(float16_t *a1, float16x4_t a2) {
- // CHECK-LABEL: test_vset_lane_f16
- return vset_lane_f16(*a1, a2, 1);
- // CHECK: [[A1:%[0-9]+]] = load i16, i16* %a1
- // CHECK: insertelement <4 x i16> %a2, i16 [[A1]], i32 1
-}
-
-float16x8_t test_vsetq_lane_f16(float16_t *a1, float16x8_t a2) {
- // CHECK-LABEL: test_vsetq_lane_f16
- return vsetq_lane_f16(*a1, a2, 4);
- // CHECK: [[A1:%[0-9]+]] = load i16, i16* %a1
- // CHECK: insertelement <8 x i16> %a2, i16 [[A1]], i32 4
-}
-
-// problem with scalar_to_vector in backend. Punt for now
-#if 0
-float64x1_t test_vset_lane_f64(float64_t a1, float64x1_t a2) {
- // CHECK-LABEL@ test_vset_lane_f64
- return vset_lane_f64(a1, a2, 0);
- // CHECK@ @llvm.aarch64.neon.smaxv.i32.v8i8
-}
-#endif
-
-float64x2_t test_vsetq_lane_f64(float64_t a1, float64x2_t a2) {
- // CHECK-LABEL: test_vsetq_lane_f64
- return vsetq_lane_f64(a1, a2, 0);
- // CHECK: insertelement <2 x double> %a2, double %a1, i32 0
-}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r245987 - [Headers][X86] Add -O0 assembly tests for avx2 intrinsics.
Author: ab
Date: Tue Aug 25 18:09:05 2015
New Revision: 245987
URL: http://llvm.org/viewvc/llvm-project?rev=245987&view=rev
Log:
[Headers][X86] Add -O0 assembly tests for avx2 intrinsics.
We agreed for r245605 that, as long as we don't affect -O0 codegen
too much, it's OK to use native constructs rather than intrinsics.
Let's test that, starting with AVX2 here.
See PR24580.
Differential Revision: http://reviews.llvm.org/D12212
Modified:
cfe/trunk/test/CodeGen/avx2-builtins.c
Modified: cfe/trunk/test/CodeGen/avx2-builtins.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx2-builtins.c?rev=245987&r1=245986&r2=245987&view=diff
==
--- cfe/trunk/test/CodeGen/avx2-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx2-builtins.c Tue Aug 25 18:09:05 2015
@@ -1,4 +1,5 @@
// RUN: %clang_cc1 %s -O0 -triple=x86_64-apple-darwin -target-feature +avx2
-emit-llvm -o - -Werror | FileCheck %s
+// RUN: %clang_cc1 %s -O0 -triple=x86_64-apple-darwin -target-feature +avx2 -S
-o - -Werror | FileCheck %s --check-prefix=CHECK-ASM
// Don't include mm_malloc.h, it's system specific.
#define __MM_MALLOC_H
@@ -7,172 +8,210 @@
__m256i test_mm256_mpsadbw_epu8(__m256i x, __m256i y) {
// CHECK: @llvm.x86.avx2.mpsadbw({{.*}}, {{.*}}, i8 3)
+ // CHECK-ASM: vmpsadbw $3, %ymm{{.*}}
return _mm256_mpsadbw_epu8(x, y, 3);
}
__m256i test_mm256_sad_epu8(__m256i x, __m256i y) {
// CHECK: @llvm.x86.avx2.psad.bw
+ // CHECK-ASM: vpsadbw %ymm{{.*}}
return _mm256_sad_epu8(x, y);
}
__m256i test_mm256_abs_epi8(__m256i a) {
// CHECK: @llvm.x86.avx2.pabs.b
+ // CHECK-ASM: vpabsb %ymm{{.*}}
return _mm256_abs_epi8(a);
}
__m256i test_mm256_abs_epi16(__m256i a) {
// CHECK: @llvm.x86.avx2.pabs.w
+ // CHECK-ASM: vpabsw %ymm{{.*}}
return _mm256_abs_epi16(a);
}
__m256i test_mm256_abs_epi32(__m256i a) {
// CHECK: @llvm.x86.avx2.pabs.d
+ // CHECK-ASM: vpabsd %ymm{{.*}}
return _mm256_abs_epi32(a);
}
__m256i test_mm256_packs_epi16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packsswb
+ // CHECK-ASM: vpacksswb %ymm{{.*}}
return _mm256_packs_epi16(a, b);
}
__m256i test_mm256_packs_epi32(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packssdw
+ // CHECK-ASM: vpackssdw %ymm{{.*}}
return _mm256_packs_epi32(a, b);
}
__m256i test_mm256_packs_epu16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packuswb
+ // CHECK-ASM: vpackuswb %ymm{{.*}}
return _mm256_packus_epi16(a, b);
}
__m256i test_mm256_packs_epu32(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packusdw
+ // CHECK-ASM: vpackusdw %ymm{{.*}}
return _mm256_packus_epi32(a, b);
}
__m256i test_mm256_add_epi8(__m256i a, __m256i b) {
// CHECK: add <32 x i8>
+ // CHECK-ASM: vpaddb %ymm{{.*}}
return _mm256_add_epi8(a, b);
}
__m256i test_mm256_add_epi16(__m256i a, __m256i b) {
// CHECK: add <16 x i16>
+ // CHECK-ASM: vpaddw %ymm{{.*}}
return _mm256_add_epi16(a, b);
}
__m256i test_mm256_add_epi32(__m256i a, __m256i b) {
// CHECK: add <8 x i32>
+ // CHECK-ASM: vpaddd %ymm{{.*}}
return _mm256_add_epi32(a, b);
}
__m256i test_mm256_add_epi64(__m256i a, __m256i b) {
// CHECK: add <4 x i64>
+ // CHECK-ASM: vpaddq {{.*}}, %ymm{{.*}}
return _mm256_add_epi64(a, b);
}
__m256i test_mm256_adds_epi8(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.padds.b
+ // CHECK-ASM: vpaddsb %ymm{{.*}}
return _mm256_adds_epi8(a, b);
}
__m256i test_mm256_adds_epi16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.padds.w
+ // CHECK-ASM: vpaddsw %ymm{{.*}}
return _mm256_adds_epi16(a, b);
}
__m256i test_mm256_adds_epu8(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.paddus.b
+ // CHECK-ASM: vpaddusb %ymm{{.*}}
return _mm256_adds_epu8(a, b);
}
__m256i test_mm256_adds_epu16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.paddus.w
+ // CHECK-ASM: vpaddusw %ymm{{.*}}
return _mm256_adds_epu16(a, b);
}
__m256i test_mm256_alignr_epi8(__m256i a, __m256i b) {
// CHECK: shufflevector <32 x i8> %{{.*}}, <32 x i8> %{{.*}}, <32 x i32>
+ // CHECK-ASM: vpalignr $2, %ymm{{.*}}
return _mm256_alignr_epi8(a, b, 2);
}
__m256i test2_mm256_alignr_epi8(__m256i a, __m256i b) {
// CHECK: shufflevector <32 x i8> %{{.*}}, <32 x i8> zeroinitializer, <32 x
i32>
+ // CHECK-ASM: vpsrldq $1, %ymm{{.*}}
return _mm256_alignr_epi8(a, b, 17);
}
__m256i test_mm256_sub_epi8(__m256i a, __m256i b) {
// CHECK: sub <32 x i8>
+ // CHECK-ASM: vpsubb %ymm{{.*}}
return _mm256_sub_epi8(a, b);
}
__m256i test_mm256_sub_epi16(__m256i a, __m256i b) {
// CHECK: sub <16 x i16>
+ // CHECK-ASM: vpsubw %ymm{{.*}}
return _mm256_sub_epi16(a, b);
}
__m256i test_mm256_sub_epi32(__m256i a, __m256i b) {
// CHECK: sub <8 x i32>
+ // CHECK-ASM: vpsubd %ymm{{.*}}
return _mm256_sub_epi32(a, b);
}
__m256i test_mm256_sub_epi64(__m256i a, __m256i b) {
// CHECK
Re: [PATCH] D12212: [Headers][X86] Add -O0 assembly tests for intrinsics.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL245987: [Headers][X86] Add -O0 assembly tests for avx2
intrinsics. (authored by ab).
Changed prior to commit:
http://reviews.llvm.org/D12212?vs=32732&id=33147#toc
Repository:
rL LLVM
http://reviews.llvm.org/D12212
Files:
cfe/trunk/test/CodeGen/avx2-builtins.c
Index: cfe/trunk/test/CodeGen/avx2-builtins.c
===
--- cfe/trunk/test/CodeGen/avx2-builtins.c
+++ cfe/trunk/test/CodeGen/avx2-builtins.c
@@ -1,178 +1,217 @@
// RUN: %clang_cc1 %s -O0 -triple=x86_64-apple-darwin -target-feature +avx2 -emit-llvm -o - -Werror | FileCheck %s
+// RUN: %clang_cc1 %s -O0 -triple=x86_64-apple-darwin -target-feature +avx2 -S -o - -Werror | FileCheck %s --check-prefix=CHECK-ASM
// Don't include mm_malloc.h, it's system specific.
#define __MM_MALLOC_H
#include
__m256i test_mm256_mpsadbw_epu8(__m256i x, __m256i y) {
// CHECK: @llvm.x86.avx2.mpsadbw({{.*}}, {{.*}}, i8 3)
+ // CHECK-ASM: vmpsadbw $3, %ymm{{.*}}
return _mm256_mpsadbw_epu8(x, y, 3);
}
__m256i test_mm256_sad_epu8(__m256i x, __m256i y) {
// CHECK: @llvm.x86.avx2.psad.bw
+ // CHECK-ASM: vpsadbw %ymm{{.*}}
return _mm256_sad_epu8(x, y);
}
__m256i test_mm256_abs_epi8(__m256i a) {
// CHECK: @llvm.x86.avx2.pabs.b
+ // CHECK-ASM: vpabsb %ymm{{.*}}
return _mm256_abs_epi8(a);
}
__m256i test_mm256_abs_epi16(__m256i a) {
// CHECK: @llvm.x86.avx2.pabs.w
+ // CHECK-ASM: vpabsw %ymm{{.*}}
return _mm256_abs_epi16(a);
}
__m256i test_mm256_abs_epi32(__m256i a) {
// CHECK: @llvm.x86.avx2.pabs.d
+ // CHECK-ASM: vpabsd %ymm{{.*}}
return _mm256_abs_epi32(a);
}
__m256i test_mm256_packs_epi16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packsswb
+ // CHECK-ASM: vpacksswb %ymm{{.*}}
return _mm256_packs_epi16(a, b);
}
__m256i test_mm256_packs_epi32(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packssdw
+ // CHECK-ASM: vpackssdw %ymm{{.*}}
return _mm256_packs_epi32(a, b);
}
__m256i test_mm256_packs_epu16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packuswb
+ // CHECK-ASM: vpackuswb %ymm{{.*}}
return _mm256_packus_epi16(a, b);
}
__m256i test_mm256_packs_epu32(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.packusdw
+ // CHECK-ASM: vpackusdw %ymm{{.*}}
return _mm256_packus_epi32(a, b);
}
__m256i test_mm256_add_epi8(__m256i a, __m256i b) {
// CHECK: add <32 x i8>
+ // CHECK-ASM: vpaddb %ymm{{.*}}
return _mm256_add_epi8(a, b);
}
__m256i test_mm256_add_epi16(__m256i a, __m256i b) {
// CHECK: add <16 x i16>
+ // CHECK-ASM: vpaddw %ymm{{.*}}
return _mm256_add_epi16(a, b);
}
__m256i test_mm256_add_epi32(__m256i a, __m256i b) {
// CHECK: add <8 x i32>
+ // CHECK-ASM: vpaddd %ymm{{.*}}
return _mm256_add_epi32(a, b);
}
__m256i test_mm256_add_epi64(__m256i a, __m256i b) {
// CHECK: add <4 x i64>
+ // CHECK-ASM: vpaddq {{.*}}, %ymm{{.*}}
return _mm256_add_epi64(a, b);
}
__m256i test_mm256_adds_epi8(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.padds.b
+ // CHECK-ASM: vpaddsb %ymm{{.*}}
return _mm256_adds_epi8(a, b);
}
__m256i test_mm256_adds_epi16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.padds.w
+ // CHECK-ASM: vpaddsw %ymm{{.*}}
return _mm256_adds_epi16(a, b);
}
__m256i test_mm256_adds_epu8(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.paddus.b
+ // CHECK-ASM: vpaddusb %ymm{{.*}}
return _mm256_adds_epu8(a, b);
}
__m256i test_mm256_adds_epu16(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.paddus.w
+ // CHECK-ASM: vpaddusw %ymm{{.*}}
return _mm256_adds_epu16(a, b);
}
__m256i test_mm256_alignr_epi8(__m256i a, __m256i b) {
// CHECK: shufflevector <32 x i8> %{{.*}}, <32 x i8> %{{.*}}, <32 x i32>
+ // CHECK-ASM: vpalignr $2, %ymm{{.*}}
return _mm256_alignr_epi8(a, b, 2);
}
__m256i test2_mm256_alignr_epi8(__m256i a, __m256i b) {
// CHECK: shufflevector <32 x i8> %{{.*}}, <32 x i8> zeroinitializer, <32 x i32>
+ // CHECK-ASM: vpsrldq $1, %ymm{{.*}}
return _mm256_alignr_epi8(a, b, 17);
}
__m256i test_mm256_sub_epi8(__m256i a, __m256i b) {
// CHECK: sub <32 x i8>
+ // CHECK-ASM: vpsubb %ymm{{.*}}
return _mm256_sub_epi8(a, b);
}
__m256i test_mm256_sub_epi16(__m256i a, __m256i b) {
// CHECK: sub <16 x i16>
+ // CHECK-ASM: vpsubw %ymm{{.*}}
return _mm256_sub_epi16(a, b);
}
__m256i test_mm256_sub_epi32(__m256i a, __m256i b) {
// CHECK: sub <8 x i32>
+ // CHECK-ASM: vpsubd %ymm{{.*}}
return _mm256_sub_epi32(a, b);
}
__m256i test_mm256_sub_epi64(__m256i a, __m256i b) {
// CHECK: sub <4 x i64>
+ // CHECK-ASM: vpsubq {{.*}}, %ymm{{.*}}
return _mm256_sub_epi64(a, b);
}
__m256i test_mm256_subs_epi8(__m256i a, __m256i b) {
// CHECK: @llvm.x86.avx2.psubs.b
+ // CHECK-ASM: vpsubsb %ymm{{.*}}
return _mm256_subs_epi8(a, b);
}
__m256i test_mm256_subs_epi16(__m256i a,
Re: [PATCH] D12212: [Headers][X86] Add -O0 assembly tests for intrinsics.
ab added a comment. Thanks Simon! Replaced the FIXMEs with proper tests and committed. Whenever I have time I'll have a look at the others, filed PR24580. Repository: rL LLVM http://reviews.llvm.org/D12212 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r245992 - [Headers] Require x86-registered for r245987 codegen tests.
Author: ab Date: Tue Aug 25 18:42:55 2015 New Revision: 245992 URL: http://llvm.org/viewvc/llvm-project?rev=245992&view=rev Log: [Headers] Require x86-registered for r245987 codegen tests. Modified: cfe/trunk/test/CodeGen/avx2-builtins.c Modified: cfe/trunk/test/CodeGen/avx2-builtins.c URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx2-builtins.c?rev=245992&r1=245991&r2=245992&view=diff == --- cfe/trunk/test/CodeGen/avx2-builtins.c (original) +++ cfe/trunk/test/CodeGen/avx2-builtins.c Tue Aug 25 18:42:55 2015 @@ -1,6 +1,8 @@ // RUN: %clang_cc1 %s -O0 -triple=x86_64-apple-darwin -target-feature +avx2 -emit-llvm -o - -Werror | FileCheck %s // RUN: %clang_cc1 %s -O0 -triple=x86_64-apple-darwin -target-feature +avx2 -S -o - -Werror | FileCheck %s --check-prefix=CHECK-ASM +// REQUIRES: x86-registered-target + // Don't include mm_malloc.h, it's system specific. #define __MM_MALLOC_H ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r246094 - [ARM] Mark mcr/mrc builtin operands as required-immediate.
Author: ab
Date: Wed Aug 26 17:21:07 2015
New Revision: 246094
URL: http://llvm.org/viewvc/llvm-project?rev=246094&view=rev
Log:
[ARM] Mark mcr/mrc builtin operands as required-immediate.
An early error message is better than the "cannot select" alternative.
Modified:
cfe/trunk/include/clang/Basic/BuiltinsARM.def
cfe/trunk/test/CodeGen/builtins-arm.c
cfe/trunk/test/Sema/builtins-arm.c
Modified: cfe/trunk/include/clang/Basic/BuiltinsARM.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsARM.def?rev=246094&r1=246093&r2=246094&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsARM.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsARM.def Wed Aug 26 17:21:07 2015
@@ -48,14 +48,14 @@ BUILTIN(__builtin_arm_vcvtr_f, "ffi", "n
BUILTIN(__builtin_arm_vcvtr_d, "fdi", "nc")
// Coprocessor
-BUILTIN(__builtin_arm_mcr, "vUiUiUiUiUiUi", "")
-BUILTIN(__builtin_arm_mcr2, "vUiUiUiUiUiUi", "")
-BUILTIN(__builtin_arm_mrc, "UiUiUiUiUiUi", "")
-BUILTIN(__builtin_arm_mrc2, "UiUiUiUiUiUi", "")
+BUILTIN(__builtin_arm_mcr, "vUIiUIiUiUIiUIiUIi", "")
+BUILTIN(__builtin_arm_mcr2, "vUIiUIiUiUIiUIiUIi", "")
+BUILTIN(__builtin_arm_mrc, "UiUIiUIiUIiUIiUIi", "")
+BUILTIN(__builtin_arm_mrc2, "UiUIiUIiUIiUIiUIi", "")
BUILTIN(__builtin_arm_cdp, "vUiUiUiUiUiUi", "")
BUILTIN(__builtin_arm_cdp2, "vUiUiUiUiUiUi", "")
-BUILTIN(__builtin_arm_mcrr, "vUiUiUiUiUi", "")
-BUILTIN(__builtin_arm_mcrr2, "vUiUiUiUiUi", "")
+BUILTIN(__builtin_arm_mcrr, "vUIiUIiUiUiUIi", "")
+BUILTIN(__builtin_arm_mcrr2, "vUIiUIiUiUiUIi", "")
// CRC32
BUILTIN(__builtin_arm_crc32b, "UiUiUc", "nc")
Modified: cfe/trunk/test/CodeGen/builtins-arm.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm.c?rev=246094&r1=246093&r2=246094&view=diff
==
--- cfe/trunk/test/CodeGen/builtins-arm.c (original)
+++ cfe/trunk/test/CodeGen/builtins-arm.c Wed Aug 26 17:21:07 2015
@@ -85,6 +85,44 @@ void prefetch(int i) {
// CHECK: call {{.*}} @llvm.prefetch(i8* %{{.*}}, i32 1, i32 3, i32 0)
}
+unsigned mrc() {
+ // CHECK: define i32 @mrc()
+ // CHECK: [[R:%.*]] = {{.*}} call i32 @llvm.arm.mrc(i32 15, i32 0, i32 13,
i32 0, i32 3)
+ // CHECK-NEXT: ret i32 [[R]]
+ return __builtin_arm_mrc(15, 0, 13, 0, 3);
+}
+
+unsigned mrc2() {
+ // CHECK: define i32 @mrc2()
+ // CHECK: [[R:%.*]] = {{.*}} call i32 @llvm.arm.mrc2(i32 15, i32 0, i32 13,
i32 0, i32 3)
+ // CHECK-NEXT: ret i32 [[R]]
+ return __builtin_arm_mrc2(15, 0, 13, 0, 3);
+}
+
+void mcr(unsigned a) {
+ // CHECK: define void @mcr(i32 [[A:%.*]])
+ // CHECK: call void @llvm.arm.mcr(i32 15, i32 0, i32 [[A]], i32 13, i32 0,
i32 3)
+ __builtin_arm_mcr(15, 0, a, 13, 0, 3);
+}
+
+void mcr2(unsigned a) {
+ // CHECK: define void @mcr2(i32 [[A:%.*]])
+ // CHECK: call void @llvm.arm.mcr2(i32 15, i32 0, i32 [[A]], i32 13, i32 0,
i32 3)
+ __builtin_arm_mcr2(15, 0, a, 13, 0, 3);
+}
+
+void mcrr(unsigned a, unsigned b) {
+ // CHECK: define void @mcrr(i32 [[A:%.*]], i32 [[B:%.*]])
+ // CHECK: call void @llvm.arm.mcrr(i32 15, i32 0, i32 [[A]], i32 [[B]], i32
0)
+ __builtin_arm_mcrr(15, 0, a, b, 0);
+}
+
+void mcrr2(unsigned a, unsigned b) {
+ // CHECK: define void @mcrr2(i32 [[A:%.*]], i32 [[B:%.*]])
+ // CHECK: call void @llvm.arm.mcrr2(i32 15, i32 0, i32 [[A]], i32 [[B]], i32
0)
+ __builtin_arm_mcrr2(15, 0, a, b, 0);
+}
+
unsigned rsr() {
// CHECK: [[V0:[%A-Za-z0-9.]+]] = {{.*}} call i32
@llvm.read_register.i32(metadata !7)
// CHECK-NEXT: ret i32 [[V0]]
Modified: cfe/trunk/test/Sema/builtins-arm.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/builtins-arm.c?rev=246094&r1=246093&r2=246094&view=diff
==
--- cfe/trunk/test/Sema/builtins-arm.c (original)
+++ cfe/trunk/test/Sema/builtins-arm.c Wed Aug 26 17:21:07 2015
@@ -46,3 +46,37 @@ void test4() {
void test5() {
__builtin_arm_dbg(16); // expected-error {{argument should be a value from 0
to 15}}
}
+
+void test6(int a, int b, int c) {
+ __builtin_arm_mrc( a, 0, 13, 0, 3); // expected-error {{argument to
'__builtin_arm_mrc' must be a constant integer}}
+ __builtin_arm_mrc(15, a, 13, 0, 3); // expected-error {{argument to
'__builtin_arm_mrc' must be a constant integer}}
+ __builtin_arm_mrc(15, 0, a, 0, 3); // expected-error {{argument to
'__builtin_arm_mrc' must be a constant integer}}
+ __builtin_arm_mrc(15, 0, 13, a, 3); // expected-error {{argument to
'__builtin_arm_mrc' must be a constant integer}}
+ __builtin_arm_mrc(15, 0, 13, 0, a); // expected-error {{argument to
'__builtin_arm_mrc' must be a constant integer}}
+
+ __builtin_arm_mrc2( a, 0, 13, 0, 3); // expected-error {{argument to
'__builtin_arm_mrc2' must be a constant integer}}
+ __builtin_arm_mrc2(15, a, 13, 0, 3); // expected-error {{argument to
'__builtin_arm_m
[PATCH] D12389: Conditionalize X86 Darwin MaxVectorAlign on the presence of AVX.
ab created this revision.
ab added a reviewer: rjmccall.
ab added a subscriber: cfe-commits.
The long-overdue (sorry!) prequel to D10724.
http://reviews.llvm.org/D12389
Files:
lib/Basic/Targets.cpp
test/CodeGen/vector-alignment.c
Index: test/CodeGen/vector-alignment.c
===
--- test/CodeGen/vector-alignment.c
+++ test/CodeGen/vector-alignment.c
@@ -1,38 +1,51 @@
-// RUN: %clang_cc1 -w -triple x86_64-apple-darwin10 -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -triple x86_64-apple-darwin10 \
+// RUN: -emit-llvm -o - %s | FileCheck %s --check-prefix=ALL --check-prefix=SSE
+// RUN: %clang_cc1 -w -triple i386-apple-darwin10 \
+// RUN: -emit-llvm -o - %s | FileCheck %s --check-prefix=ALL --check-prefix=SSE
+// RUN: %clang_cc1 -w -triple x86_64-apple-darwin10 -target-feature +avx \
+// RUN: -emit-llvm -o - %s | FileCheck %s --check-prefix=ALL --check-prefix=AVX
+// RUN: %clang_cc1 -w -triple i386-apple-darwin10 -target-feature +avx \
+// RUN: -emit-llvm -o - %s | FileCheck %s --check-prefix=ALL --check-prefix=AVX
// rdar://11759609
// At or below target max alignment with no aligned attribute should align based
// on the size of vector.
double __attribute__((vector_size(16))) v1;
-// CHECK: @v1 {{.*}}, align 16
+// SSE: @v1 {{.*}}, align 16
+// AVX: @v1 {{.*}}, align 16
double __attribute__((vector_size(32))) v2;
-// CHECK: @v2 {{.*}}, align 32
+// SSE: @v2 {{.*}}, align 16
+// AVX: @v2 {{.*}}, align 32
// Alignment above target max alignment with no aligned attribute should align
// based on the target max.
double __attribute__((vector_size(64))) v3;
-// CHECK: @v3 {{.*}}, align 32
+// SSE: @v3 {{.*}}, align 16
+// AVX: @v3 {{.*}}, align 32
double __attribute__((vector_size(1024))) v4;
-// CHECK: @v4 {{.*}}, align 32
+// SSE: @v4 {{.*}}, align 16
+// AVX: @v4 {{.*}}, align 32
// Aliged attribute should always override.
double __attribute__((vector_size(16), aligned(16))) v5;
-// CHECK: @v5 {{.*}}, align 16
+// ALL: @v5 {{.*}}, align 16
double __attribute__((vector_size(16), aligned(64))) v6;
-// CHECK: @v6 {{.*}}, align 64
+// ALL: @v6 {{.*}}, align 64
double __attribute__((vector_size(32), aligned(16))) v7;
-// CHECK: @v7 {{.*}}, align 16
+// ALL: @v7 {{.*}}, align 16
double __attribute__((vector_size(32), aligned(64))) v8;
-// CHECK: @v8 {{.*}}, align 64
+// ALL: @v8 {{.*}}, align 64
// Check non-power of 2 widths.
double __attribute__((vector_size(24))) v9;
-// CHECK: @v9 {{.*}}, align 32
+// SSE: @v9 {{.*}}, align 16
+// AVX: @v9 {{.*}}, align 32
double __attribute__((vector_size(40))) v10;
-// CHECK: @v10 {{.*}}, align 32
+// SSE: @v10 {{.*}}, align 16
+// AVX: @v10 {{.*}}, align 32
// Check non-power of 2 widths with aligned attribute.
double __attribute__((vector_size(24), aligned(64))) v11;
-// CHECK: @v11 {{.*}}, align 64
+// ALL: @v11 {{.*}}, align 64
double __attribute__((vector_size(80), aligned(16))) v12;
-// CHECK: @v12 {{.*}}, align 16
+// ALL: @v12 {{.*}}, align 16
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -3622,13 +3622,21 @@
LongDoubleWidth = 128;
LongDoubleAlign = 128;
SuitableAlign = 128;
-MaxVectorAlign = 256;
SizeType = UnsignedLong;
IntPtrType = SignedLong;
DataLayoutString = "e-m:o-p:32:32-f64:32:64-f80:128-n8:16:32-S128";
HasAlignMac68kSupport = true;
}
+ bool handleTargetFeatures(std::vector &Features,
+DiagnosticsEngine &Diags) override {
+if (!DarwinTargetInfo::handleTargetFeatures(Features,
+ Diags))
+ return false;
+// Now that we know if we have AVX, we can decide how to align vectors.
+MaxVectorAlign = getABI().startswith("avx") ? 256 : 128;
+return true;
+ }
};
// x86-32 Windows target
@@ -3979,13 +3987,22 @@
DarwinX86_64TargetInfo(const llvm::Triple &Triple)
: DarwinTargetInfo(Triple) {
Int64Type = SignedLongLong;
-MaxVectorAlign = 256;
// The 64-bit iOS simulator uses the builtin bool type for Objective-C.
llvm::Triple T = llvm::Triple(Triple);
if (T.isiOS())
UseSignedCharForObjCBool = false;
DataLayoutString = "e-m:o-i64:64-f80:128-n8:16:32:64-S128";
}
+
+ bool handleTargetFeatures(std::vector &Features,
+DiagnosticsEngine &Diags) override {
+if (!DarwinTargetInfo::handleTargetFeatures(Features,
+ Diags))
+ return false;
+// Now that we know if we have AVX, we can decide how to align vectors.
+MaxVectorAlign = getABI().startswith("avx") ? 256 : 128;
+return true;
+ }
};
class OpenBSDX86_64TargetInfo : public OpenBSDTargetInfo {
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
[PATCH] D12390: Also enable the avx/avx512 ABIs for i386, not just x86_64.
ab created this revision.
ab added a reviewer: rjmccall.
ab added a subscriber: cfe-commits.
One problem that came up in D12389 is that i386 doesn't know about the "avx"
ABIs. Judging by the commit that originally introduced the X86_64 check and
the "avx" ABI (r145652), it was just unnecessary.
Because of that, we can't decide based on the ABI string only for i386.
The only effect this should have is that SimdDefaultAlign would previously
always be 128 on i386, no matter the SSE level. We will now use a larger
alignment, which seems desirable to me. I added i386 RUN lines to the OpenMP
simd test.
I also moved the no-mmx check earlier, as I gather it's necessary for
correctness with -mno-mmx (as opposed to the "avx" ABIs which make no
difference other than SIMD/vector alignment on i386).
http://reviews.llvm.org/D12390
Files:
lib/Basic/Targets.cpp
test/OpenMP/simd_metadata.c
Index: test/OpenMP/simd_metadata.c
===
--- test/OpenMP/simd_metadata.c
+++ test/OpenMP/simd_metadata.c
@@ -1,6 +1,9 @@
// RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -emit-llvm %s -o -
| FileCheck %s -check-prefix=CHECK -check-prefix=X86
// RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature
+avx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
// RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature
+avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK
-check-prefix=X86-AVX512
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -emit-llvm %s -o - |
FileCheck %s -check-prefix=CHECK -check-prefix=X86
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature +avx
-emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature
+avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK
-check-prefix=X86-AVX512
// RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -emit-llvm %s -o
- | FileCheck %s -check-prefix=CHECK -check-prefix=PPC
// RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -target-abi
elfv1-qpx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK
-check-prefix=PPC-QPX
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -2308,13 +2308,13 @@
bool handleTargetFeatures(std::vector &Features,
DiagnosticsEngine &Diags) override;
StringRef getABI() const override {
-if (getTriple().getArch() == llvm::Triple::x86_64 && SSELevel >= AVX512F)
+if (getTriple().getArch() == llvm::Triple::x86 &&
+MMX3DNowLevel == NoMMX3DNow)
+ return "no-mmx";
+else if (SSELevel >= AVX512F)
return "avx512";
-else if (getTriple().getArch() == llvm::Triple::x86_64 && SSELevel >= AVX)
+else if (SSELevel >= AVX)
return "avx";
-else if (getTriple().getArch() == llvm::Triple::x86 &&
- MMX3DNowLevel == NoMMX3DNow)
- return "no-mmx";
return "";
}
bool setCPU(const std::string &Name) override {
Index: test/OpenMP/simd_metadata.c
===
--- test/OpenMP/simd_metadata.c
+++ test/OpenMP/simd_metadata.c
@@ -1,6 +1,9 @@
// RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86
// RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature +avx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
// RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature +avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX512
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature +avx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature +avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX512
// RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=PPC
// RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -target-abi elfv1-qpx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=PPC-QPX
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -2308,13 +2308,13 @@
bool handleTargetFeatures(std::vector &Features,
DiagnosticsEngine &Diags) override;
StringRef getABI() const override {
-if (getTriple().getArch() == llvm::Triple::x86_64 && SSELevel >= AVX51
Re: [PATCH] D12390: Also enable the avx/avx512 ABIs for i386, not just x86_64.
ab added a comment. Unless I'm misunderstanding, I believe this has much less impact than you're thinking; there are three cases: - x86_64: no change (-mno-mmx is guarded by x86) - x86, with -mno-mmx: no change (because previously, we'd only set avx/avx512 for x86_64) - x86, without -mno-mmx: this will use an avx/avx512 ABI string where we'd have used "", letting us use the better alignment (only for OpenMP and vectors, I think). http://reviews.llvm.org/D12390 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D12389: Conditionalize X86 Darwin MaxVectorAlign on the presence of AVX.
ab accepted this revision. ab added a reviewer: ab. ab added a comment. This revision is now accepted and ready to land. Yep, thanks! http://reviews.llvm.org/D12389 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r246228 - [X86] Use AVX features instead of ABI to init. SimdDefaultAlign.
Author: ab
Date: Thu Aug 27 17:24:56 2015
New Revision: 246228
URL: http://llvm.org/viewvc/llvm-project?rev=246228&view=rev
Log:
[X86] Use AVX features instead of ABI to init. SimdDefaultAlign.
The ABI string only exists to communicate with TargetCodeGenInfo.
Concretely, since we only used "avx*" ABI strings on x86_64 (as AVX
doesn't affect the i386 ABIs), this meant that, when initializing
SimdDefaultAlign, we would ignore AVX/AVX512 on i386, for no good
reason.
Instead, directly check the features. A similar change for
MaxVectorAlign will follow.
Differential Revision: http://reviews.llvm.org/D12390
Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/OpenMP/simd_metadata.c
Modified: cfe/trunk/lib/Basic/Targets.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=246228&r1=246227&r2=246228&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Thu Aug 27 17:24:56 2015
@@ -2984,7 +2984,7 @@ bool X86TargetInfo::handleTargetFeatures
MMX3DNowLevel = std::max(MMX3DNowLevel, MMX);
SimdDefaultAlign =
- (getABI() == "avx512") ? 512 : (getABI() == "avx") ? 256 : 128;
+ hasFeature("avx512f") ? 512 : hasFeature("avx") ? 256 : 128;
return true;
}
Modified: cfe/trunk/test/OpenMP/simd_metadata.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/simd_metadata.c?rev=246228&r1=246227&r2=246228&view=diff
==
--- cfe/trunk/test/OpenMP/simd_metadata.c (original)
+++ cfe/trunk/test/OpenMP/simd_metadata.c Thu Aug 27 17:24:56 2015
@@ -1,6 +1,9 @@
// RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -emit-llvm %s -o -
| FileCheck %s -check-prefix=CHECK -check-prefix=X86
// RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature
+avx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
// RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature
+avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK
-check-prefix=X86-AVX512
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -emit-llvm %s -o - |
FileCheck %s -check-prefix=CHECK -check-prefix=X86
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature +avx
-emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature
+avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK
-check-prefix=X86-AVX512
// RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -emit-llvm %s -o
- | FileCheck %s -check-prefix=CHECK -check-prefix=PPC
// RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -target-abi
elfv1-qpx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK
-check-prefix=PPC-QPX
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
