summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/Targets.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Switch C compilations to C11 by default.Richard Smith2014-10-201-3/+3
| | | | | | | | This is long-since overdue, and matches GCC 5.0. This should also be backwards-compatible, because we already supported all of C11 as an extension in C99 mode. llvm-svn: 220244
* Use the triple's isiOS() method instead of checking the value directly. NFC.Bob Wilson2014-10-191-1/+1
| | | | llvm-svn: 220158
* As requested by Matt Thomas, use long long for intmax_t and int64_t onJoerg Sonnenberger2014-10-151-0/+4
| | | | | | PPC64/NetBSD. llvm-svn: 219839
* Set ABI and DescriptionString first to reduce OS specific logic.Joerg Sonnenberger2014-10-151-10/+13
| | | | | | Use switch for FreeBSD check to allow easier extension. llvm-svn: 219838
* ARM: remove ARM/Thumb distinction for preferred alignment.Tim Northover2014-10-141-60/+30
| | | | | | | | | | | | Thumb1 has legitimate reasons for preferring 32-bit alignment of types i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be a multiple of 4. However, this is a trade-off betweem code size and RAM usage; the DataLayout string is not the best place to represent it even if desired. So this patch removes the extra Thumb requirements, hopefully making ARM and Thumb completely compatible in this respect. llvm-svn: 219735
* ARM: set preferred aggregate alignment to 32 universally.Tim Northover2014-10-141-7/+7
| | | | | | | | | | | Before, ARM and Thumb mode code had different preferred alignments, which could lead to some rather unexpected results. There's justification for reducing it from the default 64-bits (wasted space), but I don't think there is for going below 32-bits. There's no actual ABI change here, just to reassure people. llvm-svn: 219720
* Adds support for the Cortex-A17 processor to ClangRenato Golin2014-10-131-3/+3
| | | | | | Patch by Matthew Wahab. llvm-svn: 219607
* [PowerPC] Reduce names from Power8Vector to P8VectorBill Schmidt2014-10-101-4/+4
| | | | | | Per Hal Finkel's review, improving typability of some variable names. llvm-svn: 219515
* [PowerPC] Add feature for Power8 vector extensionsBill Schmidt2014-10-101-1/+9
| | | | | | | | | | | | | | | | | | The current VSX feature for PowerPC specifies availability of the VSX instructions added with the 2.06 architecture version. With 2.07, the architecture adds new instructions to both the Category:Vector and Category:VSX instruction sets. Additionally, unaligned vector storage operations have improved performance. This patch adds a feature to provide access to the new instructions and performance capabilities of Power8. For compatibility with GCC, the feature is controlled via a new -mpower8-vector switch, and the feature causes the __POWER8_VECTOR__ builtin define to be generated by the preprocessor. There is a companion patch for llvm being committed at the same time. llvm-svn: 219502
* Adds 'override' to overriding methods. NFC.Fariborz Jahanian2014-10-011-13/+13
| | | | | | These were uncoveredby my yet undelivered patch. llvm-svn: 218774
* [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
OpenPOWER on IntegriCloud