summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/Targets
Commit message (Collapse)AuthorAgeFilesLines
* [X86] Define i586 and pentium preprocessor defines for -march=lakemont to ↵Craig Topper2017-11-011-0/+2
| | | | | | match GCC llvm-svn: 317069
* Basic: improve coverage for Darwin targets and fix ABISaleem Abdulrasool2017-10-281-4/+9
| | | | | | | | The existing coverage for the Darwin targets wasn't enough to catch all the variations. Improve the coverage a bit further and fix a few cases for Darwin targets. llvm-svn: 316826
* ARM: centralise SizeType, PtrDiffType, and IntPtrTypeSaleem Abdulrasool2017-10-271-31/+13
| | | | | | | | | Centralise the definitions of these compiler vended types to aid inspection to ensure that they are defined similarly. The one case that stands out is the Darwin case where the types do not match up. This fixes the API conformance for APCS-GNU as well. llvm-svn: 316810
* Filter out invalid 'target' items from being passed to LLVMErich Keane2017-10-271-0/+1
| | | | | | | | | | | | | | | | | Craig noticed that CodeGen wasn't properly ignoring the values sent to the target attribute. This patch ignores them. This patch also sets the 'default' for this checking to 'supported', since only X86 has implemented the support for checking valid CPU names and Feature Names. One test was changed to i686, since it uses a lakemont, which would otherwise be prohibited in x86_64. Differential Revision: https://reviews.llvm.org/D39357 llvm-svn: 316783
* Remove x86,x86_32/64 from isValidFeatureNameErich Keane2017-10-271-3/+0
| | | | | | | | | These are not valid values for this, and are pretty non-sensical, since LLVM doesn't understand them. Differential Revision: https://reviews.llvm.org/D39378 llvm-svn: 316781
* [X86] Add 'sse4' to X86TargetInfo::isValidFeatureNameCraig Topper2017-10-271-0/+1
| | | | | | sse4 is valid for target attribute and functions as an alias of sse4.2. llvm-svn: 316718
* [X86] Make -march=i686 an alias of -march=pentiumproCraig Topper2017-10-262-14/+3
| | | | | | | | I think the only reason they are different is because we don't set tune_i686 for -march=i686 to match GCC. But GCC 4.9.0 seems to have changed this behavior and they do set it now. So I think they can aliases now. Differential Revision: https://reviews.llvm.org/D39349 llvm-svn: 316712
* [X86] Add avx512vpopcntdq to Knights MillCraig Topper2017-10-251-0/+2
| | | | | | As indicated by Table 1-1 in Intel Architecture Instruction Set Extensions and Future Features Programming Reference from October 2017. llvm-svn: 316593
* Pull X86 "CPUKind" checking into .cpp file. [NFC]Erich Keane2017-10-232-71/+73
| | | | | | | | Preparing to do a refactor of CPU/feature checking, this patch pulls the one CPU implementation from the .h file to the .cpp file. llvm-svn: 316338
* Basic: restore {,u}intptr_t on NetBSD/ARMSaleem Abdulrasool2017-10-201-3/+4
| | | | | | | | | NetBSD uses `long int` for `intptr_t` on ARM. This was changed in SVN r316046, referenced against other compilers. However, NetBSD's reference was incorrect as the current clang behaviour is more up-to-date. Restore the original behaviour for that target. llvm-svn: 316204
* AMDGPU: Parse r600 CPU name early and expose FMAF capabilityJan Vesely2017-10-191-1/+7
| | | | | | | Improve amdgcn macro test Differential Revision: https://reviews.llvm.org/D38667 llvm-svn: 316181
* [Hexagon] Handling of new HVX flags and target-featuresSumanth Gundapaneni2017-10-182-35/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch has the following changes A new flag "-mhvx-length={64B|128B}" is introduced to specify the length of the vector. Previously we have used "-mhvx-double" for 128 Bytes. This adds the target-feature "+hvx-length{64|128}b" The "-mhvx" flag must be provided on command line to enable HVX for Hexagon. If no -mhvx-length flag is specified, a default length is picked from the arch mentioned in this priority order from either -mhvx=vxx or -mcpu. For v60 and v62 the default length is 64 Byte. For unknown versions, the length is 128 Byte. The -mhvx flag adds the target-feature "+hvxv{hvx_version}" The 64 Byte mode is soon going to be deprecated. A warning is emitted if 64 Byte is enabled. A warning is still emitted for the default 64 Byte as well. This warning can be suppressed with a -Wno flag. The "-mhvx-double" and "-mno-hvx-double" flags are deprecated. A warning is emitted if the driver sees them on commandline. "-mhvx-double" is an alias to "-mhvx-length=128B" The compilation will error out if -mhvx-length is specified with out an -mhvx/-mhvx= flag The macro HVX_LENGTH is defined and is set to the length of the vector. Eg: #define HVX_LENGTH 64 The macro HVX_ARCH is defined and is set to the version of the HVX. Eg: #define HVX_ARCH 62 Differential Revision: https://reviews.llvm.org/D38852 llvm-svn: 316102
* Basic: fix __{,U}INTPTR_TYPE__ on ARMSaleem Abdulrasool2017-10-181-1/+4
| | | | | | | | | | Darwin and OpenBSD are the only platforms which use `long int` for `__INTPTR_TYPE__`. The other platforms use `int` in 32-bit, and `long int` on 64-bit (except for VMS and Windows which are LLP64). Adjust the type definitions to match the platform definitions. We now generate the same definition as GCC on all the targets. llvm-svn: 316046
* Basic: fix `__INTPTR_TYPE__` for Windows ARMSaleem Abdulrasool2017-10-171-0/+1
| | | | | | | The `IntPtrType` for Windows ARM should be `int` as per MSVC. Adjust the type accordingly. llvm-svn: 316042
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-152-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* [X86] Add skeleton support for knm cpuCraig Topper2017-10-132-0/+10
| | | | | | | | This adds support Knights Mill CPU. Preprocessor defines match gcc's implementation. Differential Revision: https://reviews.llvm.org/D38813 llvm-svn: 315723
* [OpenCL] Add LangAS::opencl_private to represent private address space in ASTYaxun Liu2017-10-134-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
* [COFF, ARM64] Add MS builtins __dmb, __dsb, __isbMartin Storsjo2017-10-121-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D38821 llvm-svn: 315567
* [X86] Add support for 'amdfam17h' to __builtin_cpu_is to match gcc.Craig Topper2017-10-111-0/+1
| | | | | | The compiler-rt implementation already supported it, it just wasn't exposed. llvm-svn: 315517
* Driver: hoist the `wchar_t` handling to the driverSaleem Abdulrasool2017-10-065-31/+19
| | | | | | | | | | | | | | | | Move the logic for determining the `wchar_t` type information into the driver. Rather than passing the single bit of information of `-fshort-wchar` indicate to the frontend the desired type of `wchar_t` through a new `-cc1` option of `-fwchar-type` and indicate the signedness through `-f{,no-}signed-wchar`. This replicates the current logic which was spread throughout Basic into the `RenderCharacterOptions`. Most of the changes to the tests are to ensure that the frontend uses the correct type. Add a new test set under `test/Driver/wchar_t.c` to ensure that we calculate the proper types for the various cases. llvm-svn: 315126
* Add support for Myriad ma2x8x series of CPUsWalter Lee2017-10-022-4/+65
| | | | | | | | | | | | | | | Summary: Also: - Add support for some older Myriad CPUs that were missing. - Fix some incorrect compiler defines for exisitng CPUs. Reviewers: jyknight Subscribers: fedor.sergeev Differential Revision: https://reviews.llvm.org/D37551 llvm-svn: 314706
* [AMDGPU] Allow flexible register names in inline asm constraintsYaxun Liu2017-09-281-6/+73
| | | | | | | | | | | | | | | | | | | | | | | | Currently AMDGPU inline asm only allow v and s as register names in constraints. This patch allows the following register names in constraints: (n, m is unsigned integer, n < m) v s {vn} or {v[n]} {sn} or {s[n]} {S} , where S is a special register name {v[n:m]} {s[n:m]} Differential Revision: https://reviews.llvm.org/D37568 llvm-svn: 314452
* [Targets/X86] Remove unneded `return` in setMaxAtomicWidth(). NFCI.Davide Italiano2017-09-281-1/+0
| | | | llvm-svn: 314367
* [AVR] Update data layout to match current LLVM trunkDylan McKay2017-09-271-2/+1
| | | | | | The data layout was changed in r314179 to fix atomic loads and stores. llvm-svn: 314354
* Basic: support Preserve{Most,All} CC on WindowsSaleem Abdulrasool2017-09-262-0/+4
| | | | | | | Add support for the `preserve_mostcc` and `preserve_allcc` on Windows x86_64 and AArch64. This is used by Swift. llvm-svn: 314236
* [Clang] Adding missing feature to goldmontMichael Zuckerman2017-09-251-0/+1
| | | | | Change-Id: I6c22478d16b8e02ce60dae2f8c80d43bc5ab3a9c llvm-svn: 314104
* [Atomic][X8664] set max atomic inline width according to the targetWei Mi2017-09-221-1/+7
| | | | | | | | | | | This is to fix PR31620. MaxAtomicInlineWidth is set to 128 for x86_64. However for target without cx16 support, 128 atomic operation will generate __sync_* libcalls. The patch set MaxAtomicInlineWidth to 64 if the target doesn't support cx16. Differential Revision: https://reviews.llvm.org/D38046 llvm-svn: 313992
* [X86] Move even more of our CPU to feature mapping switch to use fallthroughsCraig Topper2017-09-171-44/+40
| | | | | | | | This arranges more of the Intel and AMD CPUs into fallthrough positions based on their features. We may be able to merge this new AMD set with the BTVER or BDVER sets but I didn't look that closely. Differential Revision: https://reviews.llvm.org/D37941 llvm-svn: 313497
* [X86] Remove unnecessary extra encodings from the CPU name enum in clangCraig Topper2017-09-162-72/+14
| | | | | | | | | | | | | | | | | Summary: For a lot of older CPUs we have a 1:1 mapping between CPU name and enum name. But many of them are effectively aliases of each other and as a result are always repeated together at every usage This patch removes most of the duplication. It also uses StringSwitch::Cases to make the many to one mapping in the StringSwitch more obvious. Reviewers: RKSimon, spatel, zvi, igorb Reviewed By: RKSimon Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D37938 llvm-svn: 313462
* [AMDGPU] Change addr space of clk_event_t, queue_t and reserve_id_t to globalYaxun Liu2017-09-131-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D37703 llvm-svn: 313171
* [CUDA] Added rudimentary support for CUDA-9 and sm_70.Artem Belevich2017-09-071-0/+2
| | | | | | | | | | | | | For now CUDA-9 is not included in the list of CUDA versions clang searches for, so the path to CUDA-9 must be explicitly passed via --cuda-path=. On LLVM side NVPTX added sm_70 GPU type which bumps required PTX version to 6.0, but otherwise is equivalent to sm_62 at the moment. Differential Revision: https://reviews.llvm.org/D37576 llvm-svn: 312734
* [mips] Introducing option -mabs=[legacy/2008]Petar Jovanovic2017-08-242-3/+12
| | | | | | | | | | | | | | | | | In patch r205628 using abs.[ds] instruction is forced, as they should behave in accordance with flags Has2008 and ABS2008. Unfortunately for revisions prior mips32r6 and mips64r6, abs.[ds] is not generating correct result when working with NaNs. To generate a sequence which always produce a correct result but also to allow user more control on how his code is compiled, option -mabs is added where user can choose legacy or 2008. By default legacy mode is used on revisions prior R6. Mips32r6 and mips64r6 use abs2008 mode by default. Patch by Aleksandar Beserminji Differential Revision: https://reviews.llvm.org/D35982 llvm-svn: 311669
* [Clang][x86][Inline Asm] support for GCC style inline asm - Y<x> constraintsCoby Tayree2017-08-242-18/+35
| | | | | | | | | | This patch is intended to enable the use of basic double letter constraints used in GCC extended inline asm {Yi Y2 Yz Y0 Ym Yt}. Supersedes D35205 llvm counterpart: D36369 Differential Revision: https://reviews.llvm.org/D36371 llvm-svn: 311643
* bpf: add -mcpu=# support for bpfYonghong Song2017-08-231-0/+12
| | | | | | | | | | | | | | | | | | | | | -mcpu=# will support: . generic: the default insn set . v1: insn set version 1, the same as generic . v2: insn set version 2, version 1 + additional jmp insns . probe: the compiler will probe the underlying kernel to decide proper version of insn set. Examples: $ clang -target bpf -mcpu=v1 -c t.c $ clang -target bpf -mcpu=v2 -c t.c $ clang -target bpf -mcpu=generic -c t.c $ clang -target bpf -mcpu=probe -c t.c $ clang -target bpf -mcpu=v3 -c t.c error: unknown target CPU 'v3' Signed-off-by: Yonghong Song <yhs@fb.com> Acked-by: Alexei Starovoitov <ast@kernel.org> llvm-svn: 311523
* [mips] Rename getSupportedNanEncoding() to getIEEE754Standard()Petar Jovanovic2017-08-221-2/+2
| | | | | | | | | | | Rename the function getSupportedNanEncoding() to getIEEE754Standard(), since this function will be used for non-nan related features. Patch by Aleksandar Beserminji. Differential Revision: https://reviews.llvm.org/D36824 llvm-svn: 311454
* AMDGPU: add missing amdgcn processors and testsKonstantin Zhuravlyov2017-08-181-10/+15
| | | | | | | | | | | | - gfx600 - gfx601 - gfx703 - gfx902 - gfx903 Differential Revision: https://reviews.llvm.org/D36771 llvm-svn: 311141
* [OpenCL] Allow targets to select address space per typeSven van Haastregt2017-08-151-1/+15
| | | | | | | | | | | | | Generalize getOpenCLImageAddrSpace into getOpenCLTypeAddrSpace, such that targets can select the address space per type. No functional changes intended. Initial patch by Simon Perretta. Differential Revision: https://reviews.llvm.org/D33989 llvm-svn: 310911
* [AArch64] Add support for a MinGW AArch64 targetMartin Storsjo2017-08-132-26/+65
| | | | | | Differential Revision: https://reviews.llvm.org/D36364 llvm-svn: 310798
* Revert r310057Stefan Maksimovic2017-08-112-1/+7
| | | | | | | | Bring back changes which r304953 introduced since they were in fact not the cause of failures described in r310057 commit message. llvm-svn: 310702
* [X86] Implement __builtin_cpu_isCraig Topper2017-08-102-0/+40
| | | | | | | | This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc. Differential Revision: https://reviews.llvm.org/D35449 llvm-svn: 310657
* [X86] Support 'avx5124vnniw' and 'avx5124fmaps' for __builtin_cpu_supports.Craig Topper2017-08-081-0/+2
| | | | | | They still need to be implemented in the intrinsics, the command line, and the backend. But this change isn't dependent on any of that and resolves a TODO. llvm-svn: 310386
* [AArch64] Ignore stdcall and similar on aarch64/windowsMartin Storsjo2017-08-072-0/+19
| | | | | | | | | | This is similar to what's done on arm and x86_64, where these calling conventions are silently ignored, as in SVN r245076. Differential Revision: https://reviews.llvm.org/D36105 llvm-svn: 310303
* Add OpenCL 2.0 atomic builtin functions as Clang builtinYaxun Liu2017-08-041-0/+2
| | | | | | | | | | | | | | | | | | | | | OpenCL 2.0 atomic builtin functions have a scope argument which is ideally represented as synchronization scope argument in LLVM atomic instructions. Clang supports translating Clang atomic builtin functions to LLVM atomic instructions. However it currently does not support synchronization scope of LLVM atomic instructions. Without this, users have to use LLVM assembly code to implement OpenCL atomic builtin functions. This patch adds OpenCL 2.0 atomic builtin functions as Clang builtin functions, which supports generating LLVM atomic instructions with synchronization scope operand. Currently only constant memory scope argument is supported. Support of non-constant memory scope argument will be added later. Differential Revision: https://reviews.llvm.org/D28691 llvm-svn: 310082
* Revert r304953 for release 5.0.0Stefan Maksimovic2017-08-042-7/+1
| | | | | | | | | | This is causing failures when compiling clang with -O3 as one of the structures used by clang is passed by value and uses the fastcc calling convention. Faliures manifest for stage2 mips build. llvm-svn: 310057
* Define _GNU_SOURCE for RTEMS c++Walter Lee2017-08-021-0/+2
| | | | | | | | | | | | Summary: This is required by the libc++ locale support. Reviewers: jyknight Subscribers: fedor.sergeev Differential Revision: https://reviews.llvm.org/D36121 llvm-svn: 309815
* [x86][inline-asm]Allow a pack of Control Debug to be properly pickedCoby Tayree2017-08-011-0/+1
| | | | | | | | Allows the incorporation of legit (x86) Debug Regs within inline asm stataements Differential Revision: https://reviews.llvm.org/D36074 llvm-svn: 309672
* Move RTEMS to OSTargets.hWalter Lee2017-07-312-34/+34
| | | | | | Differential Revision: https://reviews.llvm.org/D36106 llvm-svn: 309626
* [AArch64] Don't define __LP64__ when targeting WindowsMartin Storsjo2017-07-311-2/+4
| | | | | | | | | Windows/ARM64 is a LLP64 environment, so don't set this default define. Differential Revision: https://reviews.llvm.org/D36098 llvm-svn: 309619
* [Targets] Move addCygMingDefines into the arch-independent Targets.cpp (NFC)Martin Storsjo2017-07-311-24/+0
| | | | | | | | | | | | This fixes a dependency inconsistency, where addMinGWDefines in Targets.cpp (used from other architectures than X86) called the addCygMingDefines function in X86.h. This was inconsistently split in SVN r308791 (D35701). Differential Revision: https://reviews.llvm.org/D36072 llvm-svn: 309598
* [x86][inline-asm]Allow a pack of Control Regs to be properly pickedCoby Tayree2017-07-301-0/+1
| | | | | | | | Allows the incorporation of legit (x86) Control Regs within inline asm stataements Differential Revision: https://reviews.llvm.org/D35903 llvm-svn: 309508
OpenPOWER on IntegriCloud