summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/Targets
Commit message (Collapse)AuthorAgeFilesLines
...
* [x86/retpoline] Split the LLVM concept of retpolines into separateChandler Carruth2018-08-232-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subtarget features for indirect calls and indirect branches. This is in preparation for enabling *only* the call retpolines when using speculative load hardening. I've continued to use subtarget features for now as they continue to seem the best fit given the lack of other retpoline like constructs so far. The LLVM side is pretty simple. I'd like to eventually get rid of the old feature, but not sure what backwards compatibility issues that will cause. This does remove the "implies" from requesting an external thunk. This always seemed somewhat questionable and is now clearly not desirable -- you specify a thunk the same way no matter which set of things are getting retpolines. I really want to keep this nicely isolated from end users and just an LLVM implementation detail, so I've moved the `-mretpoline` flag in Clang to no longer rely on a specific subtarget feature by that name and instead to be directly handled. In some ways this is simpler, but in order to preserve existing behavior I've had to add some fallback code so that users who relied on merely passing -mretpoline-external-thunk continue to get the same behavior. We should eventually remove this I suspect (we have never tested that it works!) but I've not done that in this patch. Differential Revision: https://reviews.llvm.org/D51150 llvm-svn: 340515
* [clang][mips] Set __mips_fpr correctly for -mfpxxStefan Maksimovic2018-08-222-16/+63
| | | | | | | | | | | | | | | | | | | | Set __mips_fpr to 0 if o32 ABI is used with either -mfpxx or none of -mfp32, -mfpxx, -mfp64 being specified. Introduce additional checks: -mfpxx is only to be used in conjunction with the o32 ABI. report an error when incompatible options are provided. Formerly no errors were raised when combining n32/n64 ABIs with -mfp32 and -mfpxx. There are other cases when __mips_fpr should be set to 0 that are not covered, ex. using o32 on a mips64 cpu which is valid but not supported in the backend as of yet. Differential Revision: https://reviews.llvm.org/D50557 llvm-svn: 340391
* AMDGPU: Move target code into TargetParserMatt Arsenault2018-08-212-193/+77
| | | | llvm-svn: 340292
* AMDGPU: Correct errors in device tableMatt Arsenault2018-08-161-2/+2
| | | | llvm-svn: 339934
* AMDGPU: Fix enabling denormals by default on pre-VI targetsMatt Arsenault2018-08-082-66/+68
| | | | | | | | Fast FMAF is not a sufficient condition to enable denormals. Before VI, enabling denormals caused F32 instructions to run at F64 speeds. llvm-svn: 339278
* AMDGPU: Add builtin for s_dcache_wbMatt Arsenault2018-08-071-0/+1
| | | | llvm-svn: 339110
* AMDGPU: Add builtin for s_dcache_inv_volMatt Arsenault2018-08-071-1/+3
| | | | llvm-svn: 339109
* Try to make builtin address space declarations not uselessMatt Arsenault2018-08-021-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way address space declarations for builtins currently work is nearly useless. The code assumes the address spaces used for builtins is a confusingly named "target address space" from user code using __attribute__((address_space(N))) that matches the builtin declaration. There's no way to use this to declare a builtin that returns a language specific address space. The terminology used is highly cofusing since it has nothing to do with the the address space selected by the target to use for a language address space. This feature is essentially unused as-is. AMDGPU and NVPTX are the only in-tree targets attempting to use this. The AMDGPU builtins certainly do not behave as intended (i.e. all of the builtins returning pointers can never compile because the numbered address space never matches the expected named address space). The NVPTX builtins are missing tests for some, and the others seem to rely on an implicit addrspacecast. Change the used address space for builtins based on a target hook to allow using a language address space for a builtin. This allows the same builtin declaration to be used for multiple languages with similarly purposed address spaces (e.g. the same AMDGPU builtin can be used in OpenCL and CUDA even though the constant address spaces are arbitarily different). This breaks the possibility of using arbitrary numbered address spaces alongside the named address spaces for builtins. If this is an issue we probably need to introduce another builtin declaration character to distinguish language address spaces from so-called "target address spaces". llvm-svn: 338707
* [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
OpenPOWER on IntegriCloud