bcm5719-llvm/clang/lib/Headers, branch meklort-10.0.1 Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-02-12T13:49:56+00:00 [X86] Cast to __v4hi instead of __m64 in the implementation of _mm_extract_pi16 and _mm_insert_pi16. 2020-02-12T13:49:56+00:00 Craig Topper craig.topper@gmail.com 2020-01-22T21:59:14+00:00 urn:sha1:533d98bdced6f75d0c7e4f42476b3bc873a113b6 __m64 is a vector of 1 long long. But the builtins these intrinsics are calling expect a vector of 4 shorts. Fixes PR44589 (cherry picked from commit 16b9410caa35da976fa5f3cf6dd3d6f3776d51ca) [CUDA] Assume the latest known CUDA version if we've found an unknown one. 2020-01-29T20:18:27+00:00 Artem Belevich tra@google.com 2020-01-22T20:44:22+00:00 urn:sha1:5777899f146aaa53f598e6978702a7a2725200d7 This makes clang somewhat forward-compatible with new CUDA releases without having to patch it for every minor release without adding any new function. If an unknown version is found, clang issues a warning (can be disabled with -Wno-cuda-unknown-version) and assumes that it has detected the latest known version. CUDA releases are usually supersets of older ones feature-wise, so it should be sufficient to keep released clang versions working with minor CUDA updates without having to upgrade clang, too. Differential Revision: https://reviews.llvm.org/D73231 (cherry picked from commit 12fefeef203ab4ef52d19bcdbd4180608a4deae1) [CUDA] Fix order of memcpy arguments in __shfl_*(<64-bit type>). 2020-01-24T23:07:22+00:00 Artem Belevich tra@google.com 2020-01-22T23:12:49+00:00 urn:sha1:0df13627c6a4006de39e5f01d81a338793b0e82b Wrong argument order resulted in broken shfl ops for 64-bit types. (cherry picked from commit cc14de88da27a8178976972bdc8211c31f7ca9ae) Work around PR43337: don't try to use the vec_sel overloads for vector long long, since clang's <altivec.h> doesn't provide it yet! 2020-01-17T08:45:35+00:00 Richard Smith richard-llvm@metafoo.co.uk 2019-09-17T03:36:55+00:00 urn:sha1:fdb501e59f25e59b9dff7d51db468d590909cfef (cherry picked from commit 388eaa1270c2762d61b756759b6db8cf15bd3a83) [X86] Mark various pointer arguments in builtins as const 2019-12-19T19:42:11+00:00 Warren Ristow warren_ristow@playstation.sony.com 2019-12-19T19:40:50+00:00 urn:sha1:7fcd9e3f70830a9c4bf631a602c2764180b5c3a8 Enabling `-Wcast-qual` identified many casts in various system headers that were dropping the `const` qualifier. Fixing those missing qualifiers pointed out that a few of the definitions of the builtins did not properly identify their arguments as `const` pointers. This commit fixes those builtin definitions, and the system header files so that they no longer drop the qualifier. Differential Revision: https://reviews.llvm.org/D71718 [ARM][CMSE] Add CMSE header and builtins 2019-12-12T15:01:14+00:00 Momchil Velikov momchil.velikov@arm.com 2019-12-12T14:59:04+00:00 urn:sha1:600d123c6ff16180a20ebb9b55476257bf69513a This is patch C2 as mentioned in RFC http://lists.llvm.org/pipermail/cfe-dev/2019-March/061834.html This adds CMSE builtin functions, and introduces arm_cmse.h header which has useful macros, functions, and data types for end-users of CMSE. Patch by Javed Absar. Diferential Revision: https://reviews.llvm.org/D70817 [X86] Remove forward declaration of _invpcid from intrin.h. Rely on inline version from immintrin.h 2019-11-26T00:27:39+00:00 Craig Topper craig.topper@intel.com 2019-11-26T00:07:37+00:00 urn:sha1:890c6ef1fb1350dd8e6b7b25da411cffbeaf6553 The forward declaration had a cdecl calling convention, but the inline version did not. This leads to a conflict if the default calling convention is not cdecl. Fix this by just removing the forward declaration. Fixes PR41503 [X86] Fix the implementation of __readcr3/__writecr3 to work in 64-bit mode 2019-11-14T21:21:36+00:00 Craig Topper craig.topper@intel.com 2019-11-14T21:21:35+00:00 urn:sha1:3cec2a17de744900401c83aedb442e2acc1f23f8 We need to use a 64-bit type in 64-bit mode so a 64-bit register will get used in the generated assembly. I've also changed the constraints to just use "r" intead of "q". "q" forces to a only an a/b/c/d register in 32-bit mode, but I see no reason that would matter here. Fixes Nico's note in PR19301 over 4 years ago. Differential Revision: https://reviews.llvm.org/D70101 [PowerPC][Altivec] Fix offsets for vec_xl and vec_xst 2019-11-08T02:58:11+00:00 Nemanja Ivanovic nemanjai@ca.ibm.com 2019-11-08T02:58:11+00:00 urn:sha1:e0407f54965318247c8fece2dfa5c9023acf0973 As we currently have it implemented in altivec.h, the offsets for these two intrinsics are element offsets. The documentation in the ABI (as well as the implementation in both XL and GCC) states that these should be byte offsets. Differential revision: https://reviews.llvm.org/D63636 [PowerPC][Altivec] Emit correct builtin for single precision vec_all_ne 2019-11-08T02:40:32+00:00 Nemanja Ivanovic nemanjai@ca.ibm.com 2019-11-08T02:40:32+00:00 urn:sha1:070e4027b02453f0962e5b61335a517581c5528f We currently emit a double precision comparison instruction for this, whereas we need to emit the single precision version. Differential revision: https://reviews.llvm.org/D64024