summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
...
* This reverts "r327189 - [ARM] Add ARMv8.2-A FP16 vector intrinsic"Sjoerd Meijer2018-03-132-10/+0
| | | | | | | This is causing problems in testing, and PR36683 was raised. Reverting it until we have sorted out how to pass f16 vectors. llvm-svn: 327437
* [ARM] Add ARMv8.2-A FP16 vector intrinsicAbderrazek Zaafrani2018-03-092-0/+10
| | | | | | | | Add the fp16 neon vector intrinsic for ARM as described in the ARM ACLE document. Reviews in https://reviews.llvm.org/D43650 llvm-svn: 327189
* Correct the alignment for the PS4 targetMatthew Voss2018-03-071-0/+1
| | | | | | https://reviews.llvm.org/D44218 llvm-svn: 326942
* [AMDGPU] Clean up old address space mapping and fix constant address space valueYaxun Liu2018-03-052-93/+47
| | | | | | Differential Revision: https://reviews.llvm.org/D43911 llvm-svn: 326725
* [WebAssembly] Add exception handling optionHeejin Ahn2018-03-022-1/+11
| | | | | | | | | | | | Summary: Add exception handling option to clang. Reviewers: dschuff Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits Differential Revision: https://reviews.llvm.org/D43681 llvm-svn: 326517
* AMDGPU: Define FP_FAST_FMA{F} macros for amdgcnKonstantin Zhuravlyov2018-02-272-148/+194
| | | | | | | | | | - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
* Fix for LLVM r326109David Zarzycki2018-02-261-2/+4
| | | | llvm-svn: 326110
* [RISCV] Enable __int128_t and __uint128_t through clang flagMandeep Singh Grang2018-02-251-1/+3
| | | | | | | | | | | | | | | | Summary: If the flag -fforce-enable-int128 is passed, it will enable support for __int128_t and __uint128_t types. This flag can then be used to build compiler-rt for RISCV32. Reviewers: asb, kito-cheng, apazos, efriedma Reviewed By: asb, efriedma Subscribers: shiva0217, efriedma, jfb, dschuff, sdardis, sbc100, jgravelle-google, aheejin, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, cfe-commits Differential Revision: https://reviews.llvm.org/D43105 llvm-svn: 326045
* bpf: Hook target feature "alu32" with LLVMYonghong Song2018-02-231-1/+8
| | | | | | | | | | | | | | LLVM has supported a new target feature "alu32" which could be enabled or disabled by "-mattr=[+|-]alu32" when using llc. This patch link Clang with it, so it could be also done by passing related options to Clang, for example: -Xclang -target-feature -Xclang +alu32 Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Reviewed-by: Yonghong Song <yhs@fb.com> llvm-svn: 325996
* [X86] Disable CLWB in Cannon LakeCraig Topper2018-02-211-1/+2
| | | | | | | | | | | Cannon Lake does not support CLWB, therefore it does not include all features listed under SKX. Patch by Gabor Buella Differential Revision: https://reviews.llvm.org/D43459 llvm-svn: 325655
* [mips] Spectre variant two mitigation for MIPSR2Simon Dardis2018-02-211-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides mitigation for CVE-2017-5715, Spectre variant two, which affects the P5600 and P6600. It provides the option -mindirect-jump=hazard, which instructs the LLVM backend to replace indirect branches with their hazard barrier variants. This option is accepted when targeting MIPS revision two or later. The migitation strategy suggested by MIPS for these processors is to use two hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard barrier variants of the 'jalr' and 'jr' instructions respectively. These instructions impede the execution of instruction stream until architecturally defined hazards (changes to the instruction stream, privileged registers which may affect execution) are cleared. These instructions in MIPS' designs are not speculated past. These instructions are used with the option -mindirect-jump=hazard when branching indirectly and for indirect function calls. These instructions are defined by the MIPS32R2 ISA, so this mitigation method is not compatible with processors which implement an earlier revision of the MIPS ISA. Implementation note: I've opted to provide this as an -mindirect-jump={hazard,...} style option in case alternative mitigation methods are required for other implementations of the MIPS ISA in future, e.g. retpoline style solutions. Reviewers: atanasyan Differential Revision: https://reviews.llvm.org/D43487 llvm-svn: 325651
* [AVR] Set the program address space in the data layoutDylan McKay2018-02-191-1/+1
| | | | | | This is accompanied by r325481 in LLVM. llvm-svn: 325483
* [X86] Add 'sahf' CPU feature to frontendDimitry Andric2018-02-172-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the `+sahf` feature for the backend, for bug 36028 (Incorrect use of pushf/popf enables/disables interrupts on amd64 kernels). This was originally submitted in bug 36037 by Jonathan Looney <jonlooney@gmail.com>. As described there, GCC also uses `-msahf` for this feature, and the backend already recognizes the `+sahf` feature. All that is needed is to teach clang to pass this on to the backend. The mapping of feature support onto CPUs may not be complete; rather, it was chosen to match LLVM's idea of which CPUs support this feature (see lib/Target/X86/X86.td). I also updated the affected test case (CodeGen/attr-target-x86.c) to match the emitted output. Reviewers: craig.topper, coby, efriedma, rsmith Reviewed By: craig.topper Subscribers: emaste, cfe-commits Differential Revision: https://reviews.llvm.org/D43394 llvm-svn: 325446
* [Basic] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2018-02-164-46/+49
| | | | | | other minor fixes (NFC). llvm-svn: 325412
* Reapply r325193Konstantin Zhuravlyov2018-02-152-91/+101
| | | | llvm-svn: 325203
* Revert r325193 as it breaks buildbotsKonstantin Zhuravlyov2018-02-152-101/+91
| | | | llvm-svn: 325200
* Add missing definition for class static after r325193.Richard Smith2018-02-151-1/+1
| | | | llvm-svn: 325195
* AMDGPU: Cleanup most of the macrosKonstantin Zhuravlyov2018-02-152-91/+101
| | | | | | | | | | | - Insert __AMD__ macro - Insert __AMDGPU__ macro - Insert __devicename__ macro - Add missing tests for arch macros Differential Revision: https://reviews.llvm.org/D36802 llvm-svn: 325193
* [Modules] Add more language features to be used with requires-declarationBruno Cardoso Lopes2018-02-141-0/+5
| | | | | | | | | Features added: c99, c11, c17, cplusplus14 and cplusplus17. rdar://problem/36328787 rdar://problem/36668431 llvm-svn: 325154
* [AMDGPU] Change constant addr space to 4Yaxun Liu2018-02-131-9/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D43171 llvm-svn: 325031
* [NFC] Extract method to SourceManager for traversing the macro "stack"George Karpenkov2018-02-091-0/+6
| | | | | | | | | | | | The code for going up the macro arg expansion is duplicated in many places (and we need it for the analyzer as well, so I did not want to duplicate it two more times). This patch is an NFC, so the semantics should remain the same. Differential Revision: https://reviews.llvm.org/D42458 llvm-svn: 324780
* AMDGPU: Update for datalayout changeMatt Arsenault2018-02-091-3/+3
| | | | llvm-svn: 324748
* AMDGPU/GCN: Bring processors in sync with AMDGPUUsageKonstantin Zhuravlyov2018-02-091-28/+42
| | | | | | | | | | | - Remove gfx800 - Remove gfx804 - Remove gfx901 - Remove gfx903 Differential Revision: https://reviews.llvm.org/D40045 llvm-svn: 324714
* [modules] Fix incorrect diagnostic mapping computation when a module changesRichard Smith2018-02-091-0/+90
| | | | | | | | | | | | | | | diagnostic settings using _Pragma within a macro. The AST writer had previously been assuming that all diagnostic state transitions would occur within a FileID corresponding to a file. When a diagnostic state change occured within a macro, it was unable to form a location for that state change and would instead corrupt the diagnostic state of the "root" node (and thus that of the main compilation). Also introduce a "#pragma clang __debug diag_mapping" debugging utility that I added to track this issue down. llvm-svn: 324695
* Fix UBSan issue with PPC::isValidCPUNameErich Keane2018-02-091-2/+1
| | | | | | | | Apparently storing the pointer to a StringLiteral as a StringRef caused this section of code to issue a ubsan warning. This will hopefully fix that. llvm-svn: 324687
* Add size to constexpr ArraysErich Keane2018-02-081-2/+2
| | | | | | | | What seems to be a bug in older versions of MSVC, constexpr member arrays with a redefinition (to force emission) require their initial definition to have the size between the brackets. llvm-svn: 324682
* Add Rest of Targets Support to ValidCPUList (enabling march notes)Erich Keane2018-02-0821-269/+307
| | | | | | | | | | | A followup to: https://reviews.llvm.org/D42978 Most of the rest of the Targets were pretty rote, so this patch knocks them all out at once. Differential Revision: https://reviews.llvm.org/D43057 llvm-svn: 324676
* Add NVPTX Support to ValidCPUList (enabling march notes)Erich Keane2018-02-083-0/+14
| | | | | | | | | | A followup to: https://reviews.llvm.org/D42978 This patch adds NVPTX support for enabling the march notes. Differential Revision: https://reviews.llvm.org/D43045 llvm-svn: 324675
* Add X86 Support to ValidCPUList (enabling march notes)Erich Keane2018-02-082-2/+15
| | | | | | | | | | A followup to: https://reviews.llvm.org/D42978 This patch adds X86 and X86_64 support for enabling the march notes. Differential Revision: https://reviews.llvm.org/D43041 llvm-svn: 324674
* Make march/target-cpu print a note with the list of valid values for ARMErich Keane2018-02-085-0/+17
| | | | | | | | | | | | When rejecting a march= or target-cpu command line parameter, the message is quite lacking. This patch adds a note that prints all possible values for the current target, if the target supports it. This adds support for the ARM/AArch64 targets (more to come!). Differential Revision: https://reviews.llvm.org/D42978 llvm-svn: 324673
* [NFCi] Replace a couple of usages of const StringRef& with StringRefErich Keane2018-02-073-4/+4
| | | | | | | No sense passing these by reference when a copy is about as free, and saves on potential indirection later. llvm-svn: 324540
* [Myriad] Define __ma2x5x and __ma2x8xWalter Lee2018-02-061-0/+7
| | | | | | | | | | | | Summary: Add architecture defines for ma2x5x and ma2x8x. Reviewers: jyknight Subscribers: fedor.sergeev, MartinO Differential Revision: https://reviews.llvm.org/D42882 llvm-svn: 324420
* [RISCV] Create a LinuxTargetInfo when targeting LinuxAlex Bradbury2018-02-031-0/+6
| | | | | | | | | | | | | | Previously, RISCV32TargetInfo or RISCV64TargetInfo were created unconditionally. Use LinuxTargetInfo<RISCV??TargetInfo> to ensure that the proper OS-specific defines are present. This patch only adds logic to instantiate LinuxTargetInfo and leaves a TODO, as I'm reluctant to add logic for other targets (e.g. FreeBSD, RTEMS) until I've produced and tested at least one binary for that OS+target combo. Thanks to @mgrang to reporting the issue. llvm-svn: 324170
* [AMDGPU] Switch to the new addr space mapping by defaultYaxun Liu2018-02-022-5/+2
| | | | | | | | This requires corresponding llvm change. Differential Revision: https://reviews.llvm.org/D40956 llvm-svn: 324102
* [CUDA] Added partial support for CUDA-9.1Artem Belevich2018-01-302-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang can use CUDA-9.1 now, though new APIs (are not implemented yet. The major change is that headers in CUDA-9.1 went through substantial changes that started in CUDA-9.0 which required substantial changes in the cuda compatibility headers provided by clang. There are two major issues: * CUDA SDK no longer provides declarations for libdevice functions. * A lot of device-side functions have become nvcc's builtins and CUDA headers no longer contain their implementations. This patch changes the way CUDA headers are handled if we compile with CUDA 9.x. Both 9.0 and 9.1 are affected. * Clang provides its own declarations of libdevice functions. * For CUDA-9.x clang now provides implementation of device-side 'standard library' functions using libdevice. This patch should not affect compilation with CUDA-8. There may be some observable differences for CUDA-9.0, though they are not expected to affect functionality. Tested: CUDA test-suite tests for all supported combinations of: CUDA: 7.0,7.5,8.0,9.0,9.1 GPU: sm_20, sm_35, sm_60, sm_70 Differential Revision: https://reviews.llvm.org/D42513 llvm-svn: 323713
* [X86] Add 'rdrnd' feature to silvermont to match recent gcc bug fix.Craig Topper2018-01-261-1/+1
| | | | | | gcc recently fixed this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83546 llvm-svn: 323552
* [X86] Define __IBT__ when -mibt is specified.Craig Topper2018-01-261-0/+2
| | | | llvm-svn: 323543
* Adjust MaxAtomicInlineWidth for i386/i486 targets.Wei Mi2018-01-231-3/+6
| | | | | | | | | | | | | | This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. So in this patch MaxAtomicInlineWidth is reset as follows: For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. Differential Revision: https://reviews.llvm.org/D42154 llvm-svn: 323281
* [WebAssembly] Factor out settings common to wasm32 and wasm64. NFC.Dan Gohman2018-01-231-2/+1
| | | | | | | MaxAtomicPromoteWidth and MaxAtomicInlineWidth are 64 on both wasm32 and wasm64, so they can be set in shared code. llvm-svn: 323253
* Introduce the "retpoline" x86 mitigation technique for variant #2 of the ↵Chandler Carruth2018-01-222-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre.. Summary: First, we need to explain the core of the vulnerability. Note that this is a very incomplete description, please see the Project Zero blog post for details: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The basis for branch target injection is to direct speculative execution of the processor to some "gadget" of executable code by poisoning the prediction of indirect branches with the address of that gadget. The gadget in turn contains an operation that provides a side channel for reading data. Most commonly, this will look like a load of secret data followed by a branch on the loaded value and then a load of some predictable cache line. The attacker then uses timing of the processors cache to determine which direction the branch took *in the speculative execution*, and in turn what one bit of the loaded value was. Due to the nature of these timing side channels and the branch predictor on Intel processors, this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain. The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers. However, there is no fully general alternative to indirect calls. We introduce a new construct we call a "retpoline" to implement indirect calls in a non-speculatable way. It can be thought of loosely as a trampoline for indirect calls which uses the RET instruction on x86. Further, we arrange for a specific call->ret sequence which ensures the processor predicts the return to go to a controlled, known location. The retpoline then "smashes" the return address pushed onto the stack by the call with the desired target of the original indirect call. The result is a predicted return to the next instruction after a call (which can be used to trap speculative execution within an infinite loop) and an actual indirect branch to an arbitrary address. On 64-bit x86 ABIs, this is especially easily done in the compiler by using a guaranteed scratch register to pass the target into this device. For 32-bit ABIs there isn't a guaranteed scratch register and so several different retpoline variants are introduced to use a scratch register if one is available in the calling convention and to otherwise use direct stack push/pop sequences to pass the target address. This "retpoline" mitigation is fully described in the following blog post: https://support.google.com/faqs/answer/7625886 We also support a target feature that disables emission of the retpoline thunk by the compiler to allow for custom thunks if users want them. These are particularly useful in environments like kernels that routinely do hot-patching on boot and want to hot-patch their thunk to different code sequences. They can write this custom thunk and use `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this case, on x86-64 thu thunk names must be: ``` __llvm_external_retpoline_r11 ``` or on 32-bit: ``` __llvm_external_retpoline_eax __llvm_external_retpoline_ecx __llvm_external_retpoline_edx __llvm_external_retpoline_push ``` And the target of the retpoline is passed in the named register, or in the case of the `push` suffix on the top of the stack via a `pushl` instruction. There is one other important source of indirect branches in x86 ELF binaries: the PLT. These patches also include support for LLD to generate PLT entries that perform a retpoline-style indirection. The only other indirect branches remaining that we are aware of are from precompiled runtimes (such as crt0.o and similar). The ones we have found are not really attackable, and so we have not focused on them here, but eventually these runtimes should also be replicated for retpoline-ed configurations for completeness. For kernels or other freestanding or fully static executables, the compiler switch `-mretpoline` is sufficient to fully mitigate this particular attack. For dynamic executables, you must compile *all* libraries with `-mretpoline` and additionally link the dynamic executable and all shared libraries with LLD and pass `-z retpolineplt` (or use similar functionality from some other linker). We strongly recommend also using `-z now` as non-lazy binding allows the retpoline-mitigated PLT to be substantially smaller. When manually apply similar transformations to `-mretpoline` to the Linux kernel we observed very small performance hits to applications running typical workloads, and relatively minor hits (approximately 2%) even for extremely syscall-heavy applications. This is largely due to the small number of indirect branches that occur in performance sensitive paths of the kernel. When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%. However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline. We will add detailed documentation covering these components in subsequent patches, but wanted to make the core functionality available as soon as possible. Happy for more code review, but we'd really like to get these patches landed and backported ASAP for obvious reasons. We're planning to backport this to both 6.0 and 5.0 release streams and get a 5.0 release with just this cherry picked ASAP for distros and vendors. This patch is the work of a number of people over the past month: Eric, Reid, Rui, and myself. I'm mailing it out as a single commit due to the time sensitive nature of landing this and the need to backport it. Huge thanks to everyone who helped out here, and everyone at Intel who helped out in discussions about how to craft this. Also, credit goes to Paul Turner (at Google, but not an LLVM contributor) for much of the underlying retpoline design. Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D41723 llvm-svn: 323155
* [X86] Add rdpid command line option and intrinsics.Craig Topper2018-01-202-0/+8
| | | | | | | | | | | | | | Summary: This patch adds -mrdpid/-mno-rdpid and the rdpid intrinsic. The corresponding LLVM commit has already been made. Reviewers: RKSimon, spatel, zvi, AndreiGrischenko Reviewed By: RKSimon Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D42272 llvm-svn: 323047
* [X86] Put the code that defines __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 for the ↵Craig Topper2018-01-201-2/+2
| | | | | | preprocessor with the other __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* defines. NFC llvm-svn: 323046
* [AArch64] Add ARMv8.2-A FP16 scalar intrinsicsAbderrazek Zaafrani2018-01-191-0/+2
| | | | | | https://reviews.llvm.org/D41792 llvm-svn: 323006
* [WebAssembly] Add target flags for sign-ext opcodes.Dan Gohman2018-01-192-1/+13
| | | | | | | Add -msign-ext and -mno-sign-ext to control the new sign-ext target feature. llvm-svn: 322967
* Make DiagnosticsEngine() take DiagOpts as DiagnosticsEngine.Nico Weber2018-01-171-5/+5
| | | | | | | No behavior change, but makes it a bit clearer that DiagnosticsEngine adds a ref to DiagOpts. llvm-svn: 322611
* [SystemZ] Support vector registers with inline asmUlrich Weigand2018-01-162-3/+21
| | | | | | | Allow using vector register names and the "v" constraint in inline asm to ensure compatibility with GCC. llvm-svn: 322562
* [OPENMP] Initial codegen for `target teams distribute parallel forAlexey Bataev2018-01-151-1/+1
| | | | | | | | | simd`. Added host codegen + codegen for devices with default codegen for `#pragma omp target teams distribute parallel for simd` directive. llvm-svn: 322515
* [OPENMP] Add codegen for `depend` clauses on `target` directive.Alexey Bataev2018-01-151-0/+4
| | | | | | | Added basic support for codegen of `depend` clauses on `target` directive. llvm-svn: 322501
* [RISCV] Add the RISCV target and compiler driverAlex Bradbury2018-01-114-0/+162
| | | | | | | | | As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
* [X86] Make -mavx512f imply -mfma and -mf16c in the frontend like it does in ↵Craig Topper2018-01-111-1/+5
| | | | | | | | | | the backend. Similarly, make -mno-fma and -mno-f16c imply -mno-avx512f. Withou this "-mno-sse -mavx512f" ends up with avx512f being enabled in the frontend but disabled in the backend. llvm-svn: 322245
OpenPOWER on IntegriCloud