summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/Arch
Commit message (Collapse)AuthorAgeFilesLines
* [X86] Add a Pass that builds a Condensed CFG for Load Value Injection (LVI) ↵Scott Constable2020-06-241-1/+7
| | | | | | | | | | | | | | Gadgets Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph. More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK). Also adds a new target feature to X86: +lvi-load-hardening The feature can be added via the clang CLI using -mlvi-hardening. Differential Revision: https://reviews.llvm.org/D75936
* Revert "[X86] Add a Pass that builds a Condensed CFG for Load Value ↵Craig Topper2020-06-241-7/+1
| | | | | | | | | Injection (LVI) Gadgets" This reverts commit c74dd640fd740c6928f66a39c7c15a014af3f66f. Reverting to address coding standard issues raised in post-commit review.
* [X86] Add a Pass that builds a Condensed CFG for Load Value Injection (LVI) ↵Scott Constable2020-06-241-1/+7
| | | | | | | | | | | | | | Gadgets Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph. More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK). Also adds a new target feature to X86: +lvi-load-hardening The feature can be added via the clang CLI using -mlvi-hardening. Differential Revision: https://reviews.llvm.org/D75936
* [X86] Add Indirect Thunk Support to X86 to mitigate Load Value Injection (LVI)Scott Constable2020-06-241-0/+17
| | | | | | | | | | | | | | | | | This pass replaces each indirect call/jump with a direct call to a thunk that looks like: lfence jmpq *%r11 This ensures that if the value in register %r11 was loaded from memory, then the value in %r11 is (architecturally) correct prior to the jump. Also adds a new target feature to X86: +lvi-cfi ("cfi" meaning control-flow integrity) The feature can be added via clang CLI using -mlvi-cfi. This is an alternate implementation to https://reviews.llvm.org/D75934 That merges the thunk insertion functionality with the existing X86 retpoline code. Differential Revision: https://reviews.llvm.org/D76812
* Revert "[RISCV] Add Clang frontend support for Bitmanip extension"Scott Egerton2020-01-151-3/+0
| | | | This reverts commit 57cf6ee9c84434161088c39a6f8dd2aae14eb12d.
* [RISCV] Add Clang frontend support for Bitmanip extensionScott Egerton2020-01-141-0/+3
| | | | | | | | | | | | | | Summary: This adds the __riscv_bitmanip macro and the 'b' target feature to enable it. Reviewers: asb, simoncook, lewis-revill, PaoloS, lenary Reviewed By: lenary Subscribers: Jim, rbar, johnrusso, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71553
* Make helper functions static or move them into anonymous namespaces. NFC.Benjamin Kramer2020-01-141-3/+3
|
* [Driver][PowerPC] Move powerpcspe logic from cc1 to DriverFangrui Song2020-01-101-0/+3
| | | | | | | | | Follow-up of D72014. It is more appropriate to use a target feature instead of a SubTypeArch to express the difference. Reviewed By: #powerpc, jhibbits Differential Revision: https://reviews.llvm.org/D72433
* [ARM][MVE] MVE-I should not be disabled by -mfpu=noneMomchil Velikov2020-01-091-20/+23
| | | | | | | | | | | | | | | Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
* AArch64: add missing Apple CPU names and use them by default.Tim Northover2020-01-081-4/+5
| | | | | | | | Apple's CPUs are called A7-A13 in official communication, occasionally with weird suffixes which we probably don't need to care about. This adds each one and describes its features. It also switches the default CPU to the canonical name for Cyclone, but leaves legacy support in so that existing bitcode still compiles.
* [NFC] Use isX86() instead of getArch()Jim Lin2020-01-071-2/+1
| | | | | | | | | | | | | | Summary: This is a clean up for https://reviews.llvm.org/D72247. Reviewers: MaskRay, craig.topper, jhenderson Reviewed By: MaskRay Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72320
* [clang][SystemZ] Add support for -march=nativeUlrich Weigand2019-12-162-4/+17
| | | | | | Handle -march=native in systemz::getSystemZTargetCPU, similar to how this is done on other platforms. Also change the return type to std::string instead of const char *.
* Revert "[ARM] Allocatable Global Register Variables for ARM"Carey Williams2019-11-291-33/+5
| | | | This reverts commit 2d739f98d8a53e38bf9faa88cdb6b0c2a363fb77.
* [PowerPC] Add new Future CPU for PowerPCStefan Pintilie2019-11-211-0/+1
| | | | | | | | | | | This patch will add -mcpu=future into clang for PowerPC. A CPU type is required for work that may possibly be enabled for some future Power CPU. The CPU type future will serve that purpose. This patch introduces no new functionality. It is an incremental patch on top of which Power PC work for some future CPU can be done. Differential Revision: https://reviews.llvm.org/D70262
* [ARM] Allocatable Global Register Variables for ARMAnna Welker2019-11-181-5/+33
| | | | | | | | | | | | Provides support for using r6-r11 as globally scoped register variables. This requires a -ffixed-rN flag in order to reserve rN against general allocation. If for a given GRV declaration the corresponding flag is not found, or the the register in question is the target's FP, we fail with a diagnostic. Differential Revision: https://reviews.llvm.org/D68862
* [RISCV] Match GCC `-march`/`-mabi` driver defaultsSam Elliott2019-11-152-12/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Clang/LLVM is a cross-compiler, and so we don't have to make a choice about `-march`/`-mabi` at build-time, but we may have to compute a default `-march`/`-mabi` when compiling a program. Until now, each place that has needed a default `-march` has calculated one itself. This patch adds a single place where a default `-march` is calculated, in order to avoid calculating different defaults in different places. This patch adds a new function `riscv::getRISCVArch` which encapsulates this logic based on GCC's for computing a default `-march` value when none is provided. This patch also updates the logic in `riscv::getRISCVABI` to match the logic in GCC's build system for computing a default `-mabi`. This patch also updates anywhere that `-march` is used to now use the new function which can compute a default. In particular, we now explicitly pass a `-march` value down to the gnu assembler. GCC has convoluted logic in its build system to choose a default `-march`/`-mabi` based on build options, which would be good to match. This patch is based on the logic in GCC 9.2.0. This commit's logic is different to GCC's only for baremetal targets, where we default to rv32imac/ilp32 or rv64imac/lp64 depending on the target triple. Tests have been updated to match the new logic. Reviewers: asb, luismarques, rogfer01, kito-cheng, khchen Reviewed By: asb, luismarques Subscribers: sameer.abuasal, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69383
* Add 8548 CPU definition and attributesJustin Hibbits2019-11-121-0/+2
| | | | | | | | 8548 CPU is GCC's name for the e500v2, so accept this in clang. The e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as well, as GCC does. Differential Revision: https://reviews.llvm.org/D67787
* [RISCV] Add support for -ffixed-xX flagsSimon Cook2019-10-221-0/+64
| | | | | | | | | | | This adds support for reserving GPRs such that the compiler will not choose a register for register allocation. The implementation follows the same design as for AArch64; each reserved register becomes a target feature and used for getting the reserved registers for a given MachineFunction. The backend checks that it does not need to write to any reserved register; if it does a relevant error is generated. Differential Revision: https://reviews.llvm.org/D67185
* Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner2019-10-194-0/+4
| | | | | | | | | | | | | | Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
* [Driver,ARM] Make -mfloat-abi=soft turn off MVE.Simon Tatham2019-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since `-mfloat-abi=soft` is taken to mean turning off all uses of the FP registers, it should turn off the MVE vector instructions as well as NEON and scalar FP. But it wasn't doing so. So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft` would cause the underlying LLVM to //not// support MVE (because it knows the real target feature relationships and turned off MVE when the `fpregs` feature was removed), but the clang layer still thought it //was// supported, and would misleadingly define the feature macro `__ARM_FEATURE_MVE`. The ARM driver code already has a long list of feature names to turn off when `-mfloat-abi=soft` is selected. The fix is to add the missing entries `mve` and `mve.fp` to that list. Reviewers: dmgreen Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69025 llvm-svn: 375001
* [ARM] Preserve fpu behaviour for '-crypto'Diogo N. Sampaio2019-10-141-18/+27
| | | | | | | | | | | | | | | | | | | | | Summary: This patch restores the behaviour that -fpu overwrites the architecture obtained from -march or -mcpu flags, not enforcing to disable 'crypto' if march=armv7 and mfpu=neon-fp-armv8. However, it does warn that 'crypto' is ignored when passing mfpu=crypto-neon-fp-armv8. Reviewers: peter.smith, labrinea Reviewed By: peter.smith Subscribers: nickdesaulniers, kristof.beyls, dmgreen, cfe-commits, krisb Tags: #clang Differential Revision: https://reviews.llvm.org/D67608 llvm-svn: 374785
* [mips] Set default float ABI to "soft" on FreeBSDSimon Atanasyan2019-10-092-7/+14
| | | | | | | | Initial patch by Kyle Evans. Fix PR43596 llvm-svn: 374154
* On PowerPC, Secure-PLT by default for FreeBSD 13 and higherDimitry Andric2019-09-181-1/+2
| | | | | | | | | | | | | | | | | | | Summary: In https://svnweb.freebsd.org/changeset/base/349351, FreeBSD 13 and higher transitioned to Secure-PLT for PowerPC. This part contains the changes in clang's PPC architecture defaults. Reviewers: emaste, jhibbits, hfinkel Reviewed By: jhibbits Subscribers: wuzish, nemanjai, krytarowski, kbarton, MaskRay, jsji, shchenz, steven.zhang, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67119 llvm-svn: 372261
* [mips] Pass "xgot" flag as a subtarget featureSimon Atanasyan2019-09-181-0/+7
| | | | | | | | | We need "xgot" flag in the MipsAsmParser to implement correct expansion of some pseudo instructions in case of using 32-bit GOT (XGOT). MipsAsmParser does not have reference to MipsSubtarget but has a reference to "feature bit set". llvm-svn: 372220
* [ARM] Update clang for removal of vfp2d16 and vfp2d16spEli Friedman2019-09-171-1/+1
| | | | | | | | Matching fix for https://reviews.llvm.org/D67375 (r372186). Differential Revision: https://reviews.llvm.org/D67467 llvm-svn: 372187
* [ARM] Take into account -mcpu and -mfpu options while handling 'crypto' featureDiogo N. Sampaio2019-09-111-15/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Submittin in behalf of krisb (Kristina Bessonova) <ch.bessonova@gmail.com> Summary: '+crypto' means '+aes' and '+sha2' for arch >= ARMv8 when they were not disabled explicitly. But this is correctly handled only in case of '-march' option, though the feature may also be specified through the '-mcpu' or '-mfpu' options. In the following example: $ clang -mcpu=cortex-a57 -mfpu=crypto-neon-fp-armv8 'aes' and 'sha2' are disabled that is quite unexpected: $ clang -cc1 -triple armv8--- -target-cpu cortex-a57 <...> -target-feature -sha2 -target-feature -aes -target-feature +crypto This exposed by https://reviews.llvm.org/D63936 that makes the 'aes' and 'sha2' features disabled by default. So, while handling the 'crypto' feature we need to take into account: - a CPU name, as it provides the information about architecture (if no '-march' option specified), - features, specified by the '-mcpu' and '-mfpu' options. Reviewers: SjoerdMeijer, ostannard, labrinea, dnsampaio Reviewed By: dnsampaio Subscribers: ikudrin, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66018 Author: krisb llvm-svn: 371597
* [RISCV] Make -march=rv{32,64}gc the default in RISC-V LinuxRoger Ferrer Ibanez2019-09-102-8/+14
| | | | | | | | This is the logical follow-up of D65634. Differential Revision: https://reviews.llvm.org/D66003 llvm-svn: 371496
* [RISCV] Default to ilp32d/lp64d in RISC-V LinuxRoger Ferrer Ibanez2019-09-101-3/+5
| | | | | | | | | | When running clang as a native compiler in RISC-V Linux the flag -mabi=ilp32d / -mabi=lp64d is always mandatory. This change makes it the default there. Differential Revision: https://reviews.llvm.org/D65634 llvm-svn: 371494
* [RISCV] Move architecture parsing code into its own functionRoger Ferrer Ibanez2019-09-101-140/+150
| | | | | | | | | | | I plan to reuse it in a later patch. This is almost NFC except a small change in control flow when diagnosing +d without +f. Differential Revision: https://reviews.llvm.org/D66002 llvm-svn: 371492
* [RISCV] Remove duplicated logic when determining the target ABIRoger Ferrer Ibanez2019-08-071-1/+7
| | | | | | | | We were calculating twice ilp32/lp64. Do this in one place instead. Differential Revision: https://reviews.llvm.org/D48357 llvm-svn: 368128
* Fix a typo in target featuresGeorge Burgess IV2019-07-161-1/+1
| | | | | | | | | There was a slight typo in r364352 that ended up causing our backend to complain on some x86 Android builds. This CL fixes that. Differential Revision: https://reviews.llvm.org/D64781 llvm-svn: 366276
* [clang][Driver][ARM] Favor -mfpu over default CPU featuresAlexandros Lamprineas2019-07-141-1/+5
| | | | | | | | | | | | | | | | When processing the command line options march, mcpu and mfpu, we store the implied target features on a vector. The change D62998 introduced a temporary vector, where the processed features get accumulated. When calling DecodeARMFeaturesFromCPU, which sets the default features for the specified CPU, we certainly don't want to override the features that have been explicitly specified on the command line. Therefore, the default features should appear first in the final vector. This problem became evident once I added the missing (unhandled) target features in ARM::getExtensionFeatures. Differential Revision: https://reviews.llvm.org/D63936 llvm-svn: 366027
* [Driver] Delete dead codeFangrui Song2019-07-121-1/+0
| | | | llvm-svn: 365898
* [clang][Driver][ARM] NFC: Remove unused function parameterAlexandros Lamprineas2019-07-021-7/+5
| | | | | | | | | Removes a vector reference that was added by D62998, since the preexisting function parameter is sufficient. Differential Revision: https://reviews.llvm.org/D64044 llvm-svn: 364895
* [RISCV] Avoid save-restore target feature warningSam Elliott2019-07-011-5/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: LLVM issues a warning if passed unknown target features. Neither I nor @asb noticed this until after https://reviews.llvm.org/D63498 landed. This patch stops passing the (unknown) "save-restore" target feature to the LLVM backend, but continues to emit a warning if a driver asks for `-msave-restore`. The default of assuming `-mno-save-restore` (and emitting no warnings) remains. Reviewers: asb Reviewed By: asb Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, cfe-commits, asb Tags: #clang Differential Revision: https://reviews.llvm.org/D64008 llvm-svn: 364777
* android: enable double-word CAS on x64Saleem Abdulrasool2019-06-251-0/+1
| | | | | | | | | | | The android target assumes that for the x86_64 target, the CPU supports SSE4.2 and popcnt. This implies that the CPU is Nehalem or newer. This should be sufficiently new to provide the double word compare and exchange instruction. This allows us to directly lower `__sync_val_compare_and_swap_16` to a `cmpxchg16b`. It appears that the libatomic in android's NDK does not provide the implementation for lowering calls to the library function. llvm-svn: 364352
* [RISC-V] Add -msave-restore and -mno-save-restore to clang driverSam Elliott2019-06-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The GCC RISC-V toolchain accepts `-msave-restore` and `-mno-save-restore` to control whether libcalls are used for saving and restoring the stack within prologues and epilogues. Clang currently errors if someone passes -msave-restore or -mno-save-restore. This means that people need to change build configurations to use clang. This patch adds these flags, so that clang invocations can now match gcc. As the RISC-V backend does not currently have a `save-restore` target feature, we emit a warning if someone requests `-msave-restore`. LLVM does not error if we pass the (unimplemented) target features `+save-restore` or `-save-restore`. Reviewers: asb, luismarques Reviewed By: asb Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63498 llvm-svn: 364018
* [ARM] Fix bugs introduced by the fp64/d32 rework.Simon Tatham2019-06-071-16/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
* [ARM] Allow "-march=foo+fp" to vary with fooSjoerd Meijer2019-06-052-29/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now, when clang processes an argument of the form "-march=foo+x+y+z", then instead of calling getArchExtFeature() for each of the extension names "x", "y", "z" and appending the returned string to its list of low-level subtarget features, it will call appendArchExtFeatures() which does the appending itself. The difference is that appendArchExtFeatures can add _more_ than one low-level feature name to the output feature list if it has to, and also, it gets told some information about what base architecture and CPU the extension is going to go with, which means that "+fp" can now mean something different for different CPUs. Namely, "+fp" now selects whatever the _default_ FPU is for the selected CPU and/or architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in ARMTargetParser.def. On the clang side, I adjust DecodeARMFeatures to call the new appendArchExtFeatures function in place of getArchExtFeature. This means DecodeARMFeatures needs to be passed a CPU name and an ArchKind, which meant changing its call sites to make those available, and also sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind enum value out of it instead of a string. Also, I add support here for the extension name "+fp.dp", which will automatically look through the FPU list for something that looks just like the default FPU except for also supporting double precision. Differential Revision: https://reviews.llvm.org/D60697 llvm-svn: 362601
* [ARM] Fix recent breakage of -mfpu=none.Simon Tatham2019-06-031-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recent change D60691 introduced a bug in clang when handling option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those options together should select Cortex-M4 but disable all use of hardware FP, but in fact, now hardware FP instructions can still be generated in that mode. The reason is because the handling of FPUVersion::NONE disables all the same feature names it used to, of which the base one is `vfp2`. But now there are further features below that, like `vfp2d16fp` and (following D60694) `fpregs`, which also need to be turned off to disable hardware FP completely. Added a tiny test which double-checks that compiling a simple FP function doesn't access the FP registers. Reviewers: SjoerdMeijer, dmgreen Reviewed By: dmgreen Subscribers: lebedev.ri, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62729 llvm-svn: 362380
* [PowerPC] Set the default PLT mode on musl to Secure PLTFangrui Song2019-05-301-1/+1
| | | | | | | | | | | | The musl libc only supports Secure PLT. Patch by A. Wilcox! Reviewed By: jhibbits Differential Revision: https://reviews.llvm.org/D59185 llvm-svn: 362051
* [Driver][RISCV] Simplify. NFCFangrui Song2019-05-261-31/+13
| | | | llvm-svn: 361710
* [ARM][CMSE] Add commandline option and feature macroJaved Absar2019-05-211-0/+4
| | | | | | | | | | | Defines macro ARM_FEATURE_CMSE to 1 for v8-M targets and introduces -mcmse option which for v8-M targets sets ARM_FEATURE_CMSE to 3. A diagnostic is produced when the option is given on architectures without support for Security Extensions. Reviewed By: dmgreen, snidertm Differential Revision: https://reviews.llvm.org/D59879 llvm-svn: 361261
* [ARM] Fix the extensions implied by a cpu nameDiogo N. Sampaio2019-05-091-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When using `clang -mcpu=CPUNAME+FEATURELIST`, the implied features defined by CPUNAME are not obtained, as the entire string is passed. This fixes that by spiting the cpuname string in the first `+`, if any. For example, when using ```clang -### --target=arm-arm-none-eabi -march=armv7-a -mcpu=cortex-a8+nocrc``` the intrinsic ```"target-feature" "+dsp"``` implied by `cortex-a8` is missing. Reviewers: keith.walker.arm, DavidSpickett, carwil Reviewed By: DavidSpickett Subscribers: javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61668 llvm-svn: 360324
* [AArch64] Support selecting TPIDR_EL[1-3] as the thread baseOliver Stannard2019-03-291-0/+12
| | | | | | | | | | | | | | Add an -mtp=el[0-3] option to select which of the AArch64 thread ID registers will be used for the TLS base pointer. This is a followup to rL356657 which added subtarget features to enable accesses to the privileged thread ID registers. Patch by Philip Derrin! Differential revision: https://reviews.llvm.org/D59631 llvm-svn: 357250
* Use Secure PLT as default on NetBSD/PowerPC.Joerg Sonnenberger2019-02-271-1/+1
| | | | llvm-svn: 355033
* [Driver] Fix float ABI default for Android ARMv8.Dan Albert2019-02-211-1/+1
| | | | | | | | | | | | | | | | Summary: Android doesn't regress back to soft float after ARMv7 :) Reviewers: srhines, pirama Reviewed By: srhines, pirama Subscribers: javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58477 llvm-svn: 354622
* [RISCV] Default enable RISCV linker relaxationShiva Chen2019-02-171-0/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D47127 llvm-svn: 354222
* [Driver] Default all Android ARM targets to NEON.Dan Albert2019-02-151-3/+1
| | | | | | | | | | | | | | | | | | | | Summary: There are an insignificant number of ARM Android devices that don't support NEON. Default to using NEON since that will improve performance on the majority of devices. Users that need to target non-NEON devices can still explicitly disable NEON. Reviewers: srhines, pirama, kristof.beyls Reviewed By: pirama Subscribers: efriedma, javed.absar, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58153 llvm-svn: 354166
* [Driver] Pass +reserve-x25 to backend if -ffixed-x25 is specifiedPetr Hosek2019-02-131-0/+3
| | | | | | This was accidentally omitted in r353957 breaking the Clang test. llvm-svn: 353960
OpenPOWER on IntegriCloud