summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/Targets.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DPOliver Stannard2014-10-011-3/+3
| | | | | | | | | The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modeled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218748
* Make sure aggregates are properly alligned on MSP430.Job Noorman2014-09-301-1/+1
| | | | llvm-svn: 218666
* Silence a signed/unsigned mismatch warning from MSVC; NFC.Aaron Ballman2014-09-191-1/+1
| | | | llvm-svn: 218121
* [x86] Enable broadwell target in clang.Robert Khasanov2014-09-191-5/+37
| | | | | | Added -madx option llvm-svn: 218116
* [X86, inlineasm] Do not allow using constraint 'x' for a variable larger thanAkira Hatanaka2014-09-181-1/+2
| | | | | | | | 128-bit unless the target CPU supports AVX. rdar://problem/11846140 llvm-svn: 218082
* [X86, inline-asm] Allow 256-bit wide operands for the 'x' constraintsHans Wennborg2014-09-181-1/+2
| | | | | | | The 'x' constraint is for "any SSE register", and GCC seems to include the 256-bit ymm registers in that concept. llvm-svn: 218073
* [X86, inlineasm] Check that the output size is correct for the given constraint.Akira Hatanaka2014-09-181-3/+23
| | | | llvm-svn: 218064
* Basic: use hex string for __ARM_FP macroSaleem Abdulrasool2014-09-181-1/+2
| | | | | | | The ARM ACLE describes the values as hex constants rather than numeric constants; follow suit. Address post-commit review comments from Jon Roelofs. llvm-svn: 218009
* [X86, inline-asm] Check that the input size is correct for constraints R, q, Q,Akira Hatanaka2014-09-171-1/+26
| | | | | | | | | | | S, D, A, y, x, f, t, and u. This is a follow-up patch for r167717. rdar://problem/11846140 rdar://problem/17476970 llvm-svn: 217994
* Basic: add support for ARM ACLE 6.5.1Saleem Abdulrasool2014-09-171-12/+32
| | | | | | | | Extend ARM ACLE support (Section 6.5.1) for AArch32. Define __ARM_FP if hardware floating point support is available as per the value defined by the ACLE. llvm-svn: 217957
* Basic: use range-based for loops for ARM targetSaleem Abdulrasool2014-09-171-19/+20
| | | | | | | Tweak handleTargetFeature for the ARM(32) target to use range based for loops. NFC. llvm-svn: 217956
* Basic: whitespace fixup for ARM target infoSaleem Abdulrasool2014-09-171-2/+1
| | | | | | Fix whitespace. NFC. llvm-svn: 217955
* [ARM] Add ACLE predefines: maxmin, rounding and h/w integer divisionJames Molloy2014-09-151-0/+8
| | | | | | Patch by Assad Hashmi! llvm-svn: 217760
* No need to use PNaCl's calling convention since PNaCl now uses a separate ↵JF Bastien2014-09-121-3/+0
| | | | | | approach for calling conventions. llvm-svn: 217696
* Add support for le64.JF Bastien2014-09-121-0/+60
| | | | | | | | | | | | | | | | | Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Also see the associated LLVM change. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5318 llvm-svn: 217694
* Fixing MSVC warning: "warning C4373: 'blah': virtual function overrides ↵Aaron Ballman2014-08-221-4/+2
| | | | | | | | 'blah', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers." This warning is basically useless because the "previous versions" being referred to is MSVC 2005 and earlier, and we obviously do not care about them. However, this warning isn't particularly chatty (I don't recall ever seeing it previously), and it has the opportunity to point out cases where the cv-qualifiers differ unintentionally (like this case), so I am leaving it enabled for now. llvm-svn: 216267
* [AArch64, inline-asm] Improve diagnostic that is printed when the size of aAkira Hatanaka2014-08-221-6/+13
| | | | | | | | | | | | | | | | | variable that has regiser constraint "r" is not 64-bit. General register operands are output using 64-bit "x" register names, regardless of the size of the variable, unless the asm operand is prefixed with the "%w" modifier. This surprises and confuses many users who aren't familiar with aarch64 inline assembly rules. With this commit, a note and fixit hint are printed which tell the users that they need modifier "%w" in order to output a "w" register instead of an "x" register. <rdar://problem/12764785> llvm-svn: 216260
* R600: Implement getPointerWidthV()Tom Stellard2014-08-211-0/+17
| | | | | | | This fixes a crash in the OCL_ImgProc/Canny OpenCV test. NOTE: This is a candidate for the 3.5 branch. llvm-svn: 216181
* R600: Add processor type for hainanTom Stellard2014-08-211-0/+1
| | | | llvm-svn: 216180
* Delete support for AuroraUX.Rafael Espindola2014-08-141-41/+2
| | | | | | auroraux.org is not resolving. llvm-svn: 215644
* Add predefined macros to identify x86_64h architectures.Bob Wilson2014-08-081-0/+4
| | | | | | Patch by Jim Grosbach. llvm-svn: 215260
* Change __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ for versions > 10.9.Bob Wilson2014-08-081-6/+17
| | | | | | | | The previous encoding only allowed a single digit for the minor version number. This changes it to use 2 digits for both the minor version and the revision number. llvm-svn: 215245
* MachO: set sizeof result type to what embedded headers expect.Tim Northover2014-08-051-2/+2
| | | | | | | | | Embedded systems seem to have inherited Darwin's choise of "unsigned long" for size_t (via a bunch of headers), so we should respect that. rdar://problem/17872787 llvm-svn: 214854
* [x32] Add __int128 supportPavel Chupin2014-08-041-0/+2
| | | | | | | | | | | | | | | | Summary: Adding __int128 support explicitly for x86_64 because currently it's on only when pointer size >= 64 which is not the case for x32. Test Plan: One of the tests using __int128 is updated Reviewers: atanasyan, chandlerc Subscribers: cfe-commits, rob.khasanov, zinovy.nis, dschuff Differential Revision: http://reviews.llvm.org/D4755 llvm-svn: 214710
* Let's assume PowerPC has no SSE.Joerg Sonnenberger2014-08-011-1/+0
| | | | llvm-svn: 214562
* [SKX] Enabling SKX target (Skylake server chip) Robert Khasanov2014-07-301-5/+56
| | | | | | | | | a) add SKX support to Clang driver; b) add tests for SKX target and AVX512BW, AVX512DQ, AVX512VL features into clang driver tests Patch by Zinovy Nis <zinovy.y.nis@intel.com> llvm-svn: 214306
* [PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= optionUlrich Weigand2014-07-281-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
* R600: Add processor type for MullinsTom Stellard2014-07-261-0/+1
| | | | llvm-svn: 213999
* Revert part of r206963James Molloy2014-07-251-0/+27
| | | | | | | | Specifically the part where we removed a warning to be compatible with GCC, which has been widely regarded as a bad idea. I'm not quite happy with how obtuse this warning is, especially in the fairly common case of a 32-bit integer literal, so I've got another patch awaiting review that adds a fixit to reduce confusion. llvm-svn: 213935
* AArch64: update Clang for merged arm64/aarch64 triples.Tim Northover2014-07-231-2/+0
| | | | | | | | | | | | | | The main subtlety here is that the Darwin tools still need to be given "-arch arm64" rather than "-arch aarch64". Fortunately this already goes via a custom function to handle weird edge-cases in other architectures, and it tested. I removed a few arm64_be tests because that really isn't an interesting thing to worry about. No-one using big-endian is also referring to the target as arm64 (at least as far as toolchains go). Mostly they date from when arm64 was a separate target and we *did* need a parallel name simply to test it at all. Now aarch64_be is sufficient. llvm-svn: 213744
* [X86 inline-asm] Error out on inline-asm constraint "=f".Akira Hatanaka2014-07-181-1/+7
| | | | | | <rdar://problem/17476689> llvm-svn: 213428
* [AArch64] Implement Clang CLI interface proposal about "-march".Kevin Qin2014-07-181-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Revert "Add default feature for CPUs on AArch64 target in Clang" at r210625. Then, all enabled feature will by passed explicitly by -target-feature in -cc1 option. 2. Get "-mfpu" deprecated. 3. Implement support of "-march". Usage is: -march=armv8-a+[no]feature For instance, "-march=armv8-a+neon+crc+nocrypto". Here "armv8-a" is necessary, and CPU names are not acceptable. Candidate features are fp, neon, crc and crypto. Where conflicting feature modifiers are specified, the right-most feature is used. 4. Implement support of "-mtune". Usage is: -march=CPU_NAME For instance, "-march=cortex-a57". This option will ONLY get micro-architectural feature enabled specifying to target CPU, like "+zcm" and "+zcz" for cyclone. Any architectural features WON'T be modified. 5. Change usage of "-mcpu" to "-mcpu=CPU_NAME+[no]feature", which is an alias to "-march={feature of CPU_NAME}+[no]feature" and "-mtune=CPU_NAME" together. Where this option is used in conjunction with -march or -mtune, those options take precedence over the appropriate part of this option. llvm-svn: 213353
* Driver: bifurcate extended and basic MSC versioningSaleem Abdulrasool2014-07-161-3/+4
| | | | | | | | | | | | | | | | | | | | | | | This restores the original behaviour of -fmsc-version. The older option remains as a mechanism for specifying the basic version information. A secondary option, -fms-compatibility-version permits the user to specify an extended version to the driver. The new version takes the value as a dot-separated value rather than the major * 100 + minor format that -fmsc-version format. This makes it easier to specify the value as well as a more flexible manner for specifying the value. Specifying both values is considered an error. The older parameter is left solely as a driver option, which is normalised into the newer parameter. This allows us to retain a single code path in the compiler itself whilst preserving the semantics of the old parameter as well as avoid having to determine which of two formats are being used by the invocation. The test changes are due to the fact that the compiler no longer supports the old option, and is a direct conversion to the new option. llvm-svn: 213119
* Drop separate UIntMaxType and just derive it from IntMaxType.Joerg Sonnenberger2014-07-141-17/+2
| | | | llvm-svn: 212987
* Introduce getCorrespondingUnsignedType() in TargetInfo to work like theJoerg Sonnenberger2014-07-141-2/+4
| | | | | | | | corresponding AST context function, only restricted to basic integer types. Use this to ensure getUIntPtrType() gives types consistent with getIntPtrType(). Fix NVPTX backend to give signed intptr_t. llvm-svn: 212982
* Fix typosAlp Toker2014-07-141-1/+1
| | | | | | Also consolidate 'backward compatibility' llvm-svn: 212974
* Remove use of uniform initialization ({}) introduced in r212725 since this ↵David Blaikie2014-07-101-1/+1
| | | | | | isn't supported in MSVC. llvm-svn: 212754
* [x32] Adding X32 target support to driver, including ↵Zinovy Nis2014-07-101-5/+11
| | | | | | | | | | TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin). The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed. Differential Revision: http://reviews.llvm.org/D4180 llvm-svn: 212725
* [mips][mips64r6] Define _MIPS_FPSET, __mips_fpr, and __mips_nan2008 ↵Daniel Sanders2014-07-091-2/+12
| | | | | | | | | | | | correctly on MIPS32r6/MIPS64r6 Summary: This removes the need to pass -mnan=2008 explicitly to be able to compile the test-suite for MIPS32r6/MIPS64r6. Differential Revision: http://reviews.llvm.org/D4433 llvm-svn: 212619
* [mips] clz is defined to give 32 for zero. Similarly, dclz gives 64.Daniel Sanders2014-07-091-0/+2
| | | | | | | | | | | | | | | Summary: While debugging another issue, I noticed that Mips currently specifies that the count leading zero builtins are undefined when the input is zero. The architecture specifications say that the clz and dclz instructions write 32 or 64 respectively when given zero. This doesn't fix any bugs that I'm aware of but it may improve optimisation in some cases. Differential Revision: http://reviews.llvm.org/D4431 llvm-svn: 212618
* ARM: use LLVM's atomicrmw instructions when ldrex/strex are available.Tim Northover2014-07-091-17/+11
| | | | | | | | | | | | | | Having some kind of weird kernel-assisted ABI for these when the native instructions are available appears to be (and should be) the exception; OSs have been gradually opting in for years and the code was getting silly. So let LLVM decide whether it's possible/profitable to inline them by default. Patch by Phoebe Buckheister. llvm-svn: 212598
* Use non-intrusive refcounting for TargetOptionsAlp Toker2014-07-061-3/+4
| | | | llvm-svn: 212388
* [Driver][Mips] Support one more MIPS CPU name - octeon.Simon Atanasyan2014-07-041-1/+5
| | | | llvm-svn: 212339
* [Driver][Mips] Support more MIPS CPU names: mips1 - mips5.Simon Atanasyan2014-07-041-0/+5
| | | | llvm-svn: 212338
* [Driver][Mips] Check MIPS CPU name provided to the Clang driver.Simon Atanasyan2014-07-031-1/+10
| | | | llvm-svn: 212260
* CodeGen: make target builtins support languagesSaleem Abdulrasool2014-07-021-0/+1
| | | | | | | | | | This extends the target builtin support to allow language specific annotations (i.e. LANGBUILTIN). This is to allow MSVC compatibility whilst retaining the ability to have EABI targets use a __builtin_ prefix. This is merely to allow uniformity in the EABI case where the unprefixed name is provided as an alias in the header. llvm-svn: 212196
* X86: inline all atomic operations up to 128-bits.Tim Northover2014-07-021-3/+1
| | | | | | | | | | The backend *can* cope with all of these now, so Clang should give it the chance. On CPUs without cmpxchg16b (e.g. the original athlon64) LLVM can reform the libcalls. rdar://problem/13496295 llvm-svn: 212173
* Driver: Handle /GR- in a compatible way with MSVCDavid Majnemer2014-07-011-1/+1
| | | | | | | | | | | | | | | | | There are slight differences between /GR- and -fno-rtti which made mapping one to the other inappropriate. -fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related information for the v-table. /GR- does not generate complete object locators and thus will not reference them in vftables. However, constructs like dynamic_cast and typeid are permitted. This should bring our implementation of RTTI up to semantic parity with MSVC modulo bugs. llvm-svn: 212138
* [Driver][Mips] MIPS ABI names "32" and "64" used as arguments of the "-mabi"Simon Atanasyan2014-07-011-6/+2
| | | | | | | | | command line option only. Internally we convert them to the "o32" and "n64" respectively. So we do not need to refer them anywhere after that conversion. No functional changes. llvm-svn: 212096
* Basic: correct the va_list type on Windows on ARMSaleem Abdulrasool2014-06-291-0/+3
| | | | | | | | | Windows on ARM defines va_list as a typedef for char *. Although the semantics of argument passing for variadic functions matches AAPCS VFP, the wrapped struct __va_list type is unused. This makes the intrinsic definition for va_list match that of Visual Studio. llvm-svn: 212004
OpenPOWER on IntegriCloud