summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/Targets
Commit message (Collapse)AuthorAgeFilesLines
* Merging r340666:Hans Wennborg2018-08-241-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r340666 | hans | 2018-08-25 00:46:33 +0200 (Sat, 25 Aug 2018) | 21 lines Revert r323281 "Adjust MaxAtomicInlineWidth for i386/i486 targets." As reported on http://lists.llvm.org/pipermail/cfe-dev/2018-August/058760.html, this broke i386-freebsd11 due to its lack of atomic 64 bit primitives. While that's not really this commit's fault, let's revert back to the old behaviour until this can be fixed. This means generating cmpxchg8b etc for i386 and i486 which don't technically support those, but that's been the behaviour for a long time, so a little longer probably doesn't hurt that much. > Adjust MaxAtomicInlineWidth for i386/i486 targets. > > This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. > Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, > i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. > So in this patch MaxAtomicInlineWidth is reset as follows: > For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. > For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. > For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. > > Differential Revision: https://reviews.llvm.org/D42154 ------------------------------------------------------------------------ llvm-svn: 340667
* [AArch64][ARM] Add Armv8.4-A testsSjoerd Meijer2018-08-011-0/+4
| | | | | | | | | This adds tests for Armv8.4-A, and also some v8.2 and v8.3 tests that were missing. Differential Revision: https://reviews.llvm.org/D50068 llvm-svn: 338525
* Remove trailing spaceFangrui Song2018-07-302-5/+5
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [ARM64] [Windows] Follow MS X86_64 C++ ABI when passing structsSanjin Sijaric2018-07-263-1/+8
| | | | | | | | | | | | | | | | | Summary: Microsoft's C++ object model for ARM64 is the same as that for X86_64. For example, small structs with non-trivial copy constructors or virtual function tables are passed indirectly. Currently, they are passed in registers when compiled with clang. Reviewers: rnk, mstorsjo, TomTan, haripul, javed.absar Reviewed By: rnk, mstorsjo Subscribers: kristof.beyls, chrib, llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D49770 llvm-svn: 338076
* [WebAssembly] Change size_t to `unsigned long`.Dan Gohman2018-07-241-3/+5
| | | | | | | | | | | | Changing it to unsigned long (which is 32-bit on wasm32) makes it the same type as wasm64 (where unsigned long is 64-bit), which would eliminate the most common cause for mangled names being different between wasm32 and wasm64. For example, export lists containing symbol names could now often be the same between wasm32 and wasm64. Differential Revision: https://reviews.llvm.org/D40526 llvm-svn: 337783
* NFC: Add the emacs c++ mode hint "-*- C++ -*-" to the headers that don't have itErik Pilkington2018-07-241-1/+1
| | | | | | https://llvm.org/docs/CodingStandards.html#file-headers llvm-svn: 337780
* [MS] Update _MSVC_LANG values for C++17 and C++2aReid Kleckner2018-07-231-2/+4
| | | | | | Fixes PR38262 llvm-svn: 337715
* Implement cpu_dispatch/cpu_specific MultiversioningErich Keane2018-07-202-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning. This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions. This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units. The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions. Differential Revision: https://reviews.llvm.org/D47474 llvm-svn: 337552
* [AArch64] Define TARGET_HEADER_BUILTINMartin Storsjo2018-07-181-0/+2
| | | | | | | Without it, the new intrinsics became available for all language variants. This was missed in SVN r337327. llvm-svn: 337352
* Always use __mcount on NetBSD. Some platforms don't provide _mcount.Joerg Sonnenberger2018-07-171-1/+1
| | | | llvm-svn: 337277
* By popular demand, switch in64_t on NetBSD/AArch64 and NetBSD/PowerPC64Joerg Sonnenberger2018-07-172-9/+2
| | | | | | to long for consistency with other 64bit platforms. llvm-svn: 337271
* [Hexagon] Diagnose intrinsics not supported by selected CPU/HVXKrzysztof Parzyszek2018-07-121-0/+4
| | | | llvm-svn: 336933
* Use Triple::isMIPS() instead of enumerating all Triples. NFCAlexander Richardson2018-06-252-13/+4
| | | | | | | | Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D48549 llvm-svn: 335495
* [SPIR] Prevent SPIR targets from using half conversion intrinsicsSjoerd Meijer2018-06-201-0/+5
| | | | | | | | | | | | | | | | | | | | | The SPIR target currently allows for half precision floating point types to be emitted using the LLVM intrinsic functions which convert half types to floats and doubles. However, this is illegal in SPIR as the only intrinsic allowed by SPIR is memcpy, as per section 3 of the SPIR specification. Currently this is leading to an assert being hit in the Clang CodeGen when attempting to emit a constant or literal _Float16 type in a comparison operation on a SPIR or SPIR64 target. This assert stems from the CodeGen attempting to emit a constant half value as an integer because the backend has specified that it is using these half conversion intrinsics (which represents half as i16). This patch prevents SPIR targets from using these intrinsics by overloading the responsible target info method, marks SPIR targets as having a legal half type and provides additional regression testing for the _Float16 type on SPIR targets. Patch by: Stephen McGroarty Differential Revision: https://reviews.llvm.org/D48188 llvm-svn: 335111
* bpf: recognize target specific option -mattr=dwarfris in clangYonghong Song2018-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The following is the usage example with clang: bash-4.2$ clang -target bpf -O2 -g -c -Xclang -target-feature -Xclang +dwarfris t.c bash-4.2$ llvm-objdump -S -d t.o t.o: file format ELF64-BPF Disassembly of section .text: test: ; int test(void) { 0: b7 00 00 00 00 00 00 00 r0 = 0 ; return 0; 1: 95 00 00 00 00 00 00 00 exit bash-4.2$ cat t.c int test(void) { return 0; } bash-4.2$ Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 334839
* [Basic] Fix -Wreorder warningBenjamin Kramer2018-06-131-15/+12
| | | | | | Just use field initializers that don't suffer from this problem llvm-svn: 334619
* [PowerPC] The __float128 type should only be available on Power9Stefan Pintilie2018-06-132-114/+105
| | | | | | | | | | | | Diasble the use of the type __float128 for PPC machines older than Power9. The use of -mfloat128 for PPC machine older than Power9 will result in an error. Differential Revision: https://reviews.llvm.org/D48088 llvm-svn: 334613
* Revert r333791 "Cap "voluntary" vector alignment at 16 for all Darwin ↵Reid Kleckner2018-06-042-3/+7
| | | | | | | | | | | | | | platforms." Adding __attribute__((aligned(32))) to __m256 breaks the implementation of _mm256_loadu_ps on Windows. On Windows, alignment attributes have higher precedence than packing attributes. We also might want to carefully consider the consequences of changing our vector typedefs, since many users copy them and invent their own new, non-Intel specific vector type names. llvm-svn: 333958
* Cap "voluntary" vector alignment at 16 for all Darwin platforms.John McCall2018-06-012-7/+3
| | | | | | | | | | | | | | | | | | | | | This fixes two major problems: - We were not capping vector alignment as desired on 32-bit ARM. - We were using different alignments based on the AVX settings on Intel, so we did not have a consistent ABI. This is an ABI break, but we think we can get away with it because vectors tend to be used mostly in inline code (which is why not having a consistent ABI has not proven disastrous on Intel). Intel's AVX types are specified as having 32-byte / 64-byte alignment, so align them explicitly instead of relying on the base ABI rule. Note that this sort of attribute is stripped from template arguments in template substitution, so there's a possibility that code templated over vectors will produce inadequately-aligned objects. The right long-term solution for this is for alignment attributes to be interpreted as true qualifiers and thus preserved in the canonical type. llvm-svn: 333791
* [Sparc] Add floating-point register namesDaniel Cederman2018-05-301-1/+9
| | | | | | | | | | | | Reviewers: jyknight Reviewed By: jyknight Subscribers: eraman, fedor.sergeev, jrtc27, cfe-commits Differential Revision: https://reviews.llvm.org/D47137 llvm-svn: 333510
* Support Swift calling convention for PPC64 targetsBob Wilson2018-05-251-0/+9
| | | | | | | This adds basic support for the Swift calling convention with PPC64 targets. Patch provided by Atul Sowani in bug report #37223 llvm-svn: 333316
* [x86] invpcid intrinsicGabor Buella2018-05-252-0/+8
| | | | | | | | | | | | An intrinsic for an old instruction, as described in the Intel SDM. Reviewers: craig.topper, rnk Reviewed By: craig.topper, rnk Differential Revision: https://reviews.llvm.org/D47142 llvm-svn: 333256
* This patch aims to match the changes introducedAlexander Ivchenko2018-05-182-28/+7
| | | | | | | | | | | | | | | | | in gcc by https://gcc.gnu.org/ml/gcc-cvs/2018-04/msg00534.html. The -mibt feature flag is being removed, and the -fcf-protection option now also defines a CET macro and causes errors when used on non-X86 targets, while X86 targets no longer check for -mibt and -mshstk to determine if -fcf-protection is supported. -mshstk is now used only to determine availability of shadow stack intrinsics. Comes with an LLVM patch (D46882). Patch by mike.dvoretsky Differential Revision: https://reviews.llvm.org/D46881 llvm-svn: 332704
* [Solaris] Only define _REENTRANT if -pthreadRainer Orth2018-05-151-1/+2
| | | | | | | | | | | | When looking at lib/Basic/Targets/OSTargets.h, I noticed that _REENTRANT is defined unconditionally on Solaris, unlike all other targets and what either Studio cc (only define it with -mt) or gcc (only define it with -pthread) do. This patch follows that lead. Differential Revision: https://reviews.llvm.org/D41241 llvm-svn: 332343
* [X86] ptwrite intrinsicGabor Buella2018-05-102-0/+8
| | | | | | | | | | Reviewers: craig.topper, RKSimon Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46540 llvm-svn: 331962
* [CUDA] Added -f[no-]cuda-short-ptr optionArtem Belevich2018-05-091-0/+3
| | | | | | | | | The option enables use of 32-bit pointers for accessing const/local/shared memory. The feature is disabled by default. Differential Revision: https://reviews.llvm.org/D46148 llvm-svn: 331938
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-093-3/+3
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [x86] Introduce the pconfig intrinsicGabor Buella2018-05-082-0/+8
| | | | | | | | | | Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46431 llvm-svn: 331740
* [X86] directstore and movdir64b intrinsicsGabor Buella2018-05-012-0/+16
| | | | | | | | | | Reviewers: spatel, craig.topper, RKSimon Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45984 llvm-svn: 331249
* AMDGPU: Add Vega12 and Vega20Matt Arsenault2018-04-302-2/+10
| | | | | | | | Changes by Matt Arsenault Konstantin Zhuravlyov llvm-svn: 331216
* [Targets] Implement getConstraintRegister for ARM and AArch64Mikhail Maltsev2018-04-302-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The getConstraintRegister method is used by semantic checking of inline assembly statements in order to diagnose conflicts between clobber list and input/output lists. Currently ARM and AArch64 don't override getConstraintRegister, so conflicts between registers assigned to variables in asm labels and clobber lists are not diagnosed. Such conflicts can cause assertion failures in the back end and even miscompilations. This patch implements getConstraintRegister for ARM and AArch64 targets. Since these targets don't have single-register constraints, the implementation is trivial and just returns the register specified in an asm label (if any). Reviewers: eli.friedman, javed.absar, thopre Reviewed By: thopre Subscribers: rengolin, eraman, rogfer01, myatsina, kristof.beyls, cfe-commits, chrib Differential Revision: https://reviews.llvm.org/D45965 llvm-svn: 331164
* [ARM] Add __ARM_FEATURE_DOTPROD pre-defined macroOliver Stannard2018-04-272-0/+7
| | | | | | | | | | | | | | This adds a pre-defined macro to test if the compiler has support for the v8.2-A dot rpoduct intrinsics in AArch32 mode. The AAcrh64 equivalent has already been added by rL330229. The ACLE spec which describes this macro hasn't been published yet, but this is based on the final internal draft, and GCC has already implemented this. Differential revision: https://reviews.llvm.org/D46108 llvm-svn: 331038
* [Solaris] __float128 is supported on Solaris/x86Rainer Orth2018-04-231-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rebasing https://reviews.llvm.org/D40898 with GCC 5.4 on Solaris 11.4, I ran into a few instances of In file included from /vol/llvm/src/compiler-rt/local/test/asan/TestCases/Posix/asan-symbolize-sanity-test.cc:19: In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/string:40: In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/char_traits.h:39: In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:64: In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_pair.h:59: In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/move.h:57: /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/type_traits:311:39: error: __float128 is not supported on this target struct __is_floating_point_helper<__float128> ^ during make check-all. The line above is inside #if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) template<> struct __is_floating_point_helper<__float128> : public true_type { }; #endif While the libstdc++ header indicates support for __float128, clang does not, but should. The following patch implements this and fixed those errors. Differential Revision: https://reviews.llvm.org/D41240 llvm-svn: 330572
* [X86] WaitPKG intrinsicsGabor Buella2018-04-202-0/+8
| | | | | | | | | | Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45254 llvm-svn: 330463
* [AAch64] Add the __ARM_FEATURE_DOTPROD macro definitionJunmo Park2018-04-172-0/+7
| | | | | | | | | This matches what GCC does. https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/aarch64-c.c Differential Revision: https://reviews.llvm.org/D45544 llvm-svn: 330229
* [ARM] Compute a target feature which corresponds to the ARM version.Eli Friedman2018-04-161-0/+11
| | | | | | | | | | | | | | | | Currently, the interaction between the triple, the CPU, and the supported features is a mess: the driver edits the triple to indicate the supported architecture version, and the LLVM backend uses this to figure out what instructions are legal. This makes it difficult to understand what's happening, and makes it impossible to LTO together two modules with different computed architectures. Instead of relying on triple rewriting to get the correct target features, we should add the right target features explicitly. Differential Revision: https://reviews.llvm.org/D45240 llvm-svn: 330169
* [X86] Introduce archs: goldmont-plus & tremontGabor Buella2018-04-161-0/+14
| | | | | | | | | | | | Reviewers: craig.topper Reviewed By: craig.topper Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D45613 llvm-svn: 330110
* [X86] Introduce cldemote intrinsicGabor Buella2018-04-132-0/+7
| | | | | | | | | | Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45257 llvm-svn: 329993
* [x86] wbnoinvd intrinsicGabor Buella2018-04-112-0/+9
| | | | | | | | | | | | | | The WBNOINVD instruction writes back all modified cache lines in the processor’s internal cache to main memory but does not invalidate (flush) the internal caches. Reviewers: craig.topper, zvi, ashlykov Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D43817 llvm-svn: 329848
* [NVPTX] Removed 'satom' feature which is no longer used.Artem Belevich2018-04-112-2/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D45061 llvm-svn: 329830
* [NVPTX, CUDA] Improved feature constraints on NVPTX target builtins.Artem Belevich2018-04-112-0/+19
| | | | | | | | | | When NVPTX TARGET_BUILTIN specifies sm_XX or ptxYY as required feature, consider those features available if we're compiling for GPU >= sm_XX or have enabled PTX version >= ptxYY. Differential Revision: https://reviews.llvm.org/D45061 llvm-svn: 329829
* bpf: accept all asm register namesYonghong Song2018-04-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes when people compile bpf programs with "clang ... -target bpf ...", the kernel header files may contain host arch inline assembly codes as in the patch https://patchwork.kernel.org/patch/10119683/ by Arnaldo Carvaldo de Melo. The current workaround in the above patch is to guard the inline assembly with "#ifndef __BPF__" marco. So when __BPF__ is defined, these macros will have no use. Such a method is not extensible. As a matter of fact, most of these inline assembly codes will be thrown away at the end of clang compilation. So for bpf target, this patch accepts all asm register names in clang AST stage. The name will be checked again during llc code generation if the inline assembly code is indeed for bpf programs. With this patch, the above "#ifndef __BPF__" is not needed any more in https://patchwork.kernel.org/patch/10119683/. Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 329823
* [X86] Split up -march=icelake to -client & -serverGabor Buella2018-04-101-2/+4
| | | | | | | | | | Reviewers: craig.topper, zvi, echristo Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45056 llvm-svn: 329741
* [X86] Disable SGX for Skylake ServerGabor Buella2018-04-101-1/+2
| | | | | | | | | | Reviewers: craig.topper, zvi, echristo Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45058 llvm-svn: 329701
* [CUDA] Revert defining __CUDA_ARCH__ for amdgcn targetsYaxun Liu2018-04-093-10/+55
| | | | | | | | | | amdgcn targets only support HIP, which does not define __CUDA_ARCH__. this is a partial unroll of r329232 / D45277. Differential Revision: https://reviews.llvm.org/D45387 llvm-svn: 329584
* Fix typos in clangAlexander Kornienko2018-04-062-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* [PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfoShiva Chen2018-04-052-1/+64
| | | | | | | | | | | | | | Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
* [CUDA] Add amdgpu sub archsYaxun Liu2018-04-043-42/+10
| | | | | | | | | Patch by Greg Rodgers. Revised and lit tests added by Yaxun Liu. Differential Revision: https://reviews.llvm.org/D45277 llvm-svn: 329232
* [Hexagon] Remove -mhvx-double and the corresponding subtarget featureKrzysztof Parzyszek2018-04-031-1/+0
| | | | | | | Specifying the HVX vector length should be done via the -mhvx-length option. llvm-svn: 329077
* CodeGenCXX: support PreserveMostCC in MS ABISaleem Abdulrasool2018-04-021-0/+1
| | | | | | | | Microsoft has reserved 'U' for the PreserveMostCC which is used in the swift runtime. Add support for this. This allows the swift runtime to be built for Windows again. llvm-svn: 329025
OpenPOWER on IntegriCloud