summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* Added Control Flow Protection FlagOren Ben Simhon2018-01-092-0/+26
| | | | | | | | | | Cf-protection is a target independent flag that instructs the back-end to instrument control flow mechanisms like: Branch, Return, etc. For example in X86 this flag will be used to instrument Indirect Branch Tracking instructions. Differential Revision: https://reviews.llvm.org/D40478 Change-Id: I5126e766c0e6b84118cae0ee8a20fe78cc373dea llvm-svn: 322063
* Implement Attribute Target MultiVersioningErich Keane2018-01-082-0/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC's attribute 'target', in addition to being an optimization hint, also allows function multiversioning. We currently have the former implemented, this is the latter's implementation. This works by enabling functions with the same name/signature to coexist, so that they can all be emitted. Multiversion state is stored in the FunctionDecl itself, and SemaDecl manages the definitions. Note that it ends up having to permit redefinition of functions so that they can all be emitted. Additionally, all versions of the function must be emitted, so this also manages that. Note that this includes some additional rules that GCC does not, since defining something as a MultiVersion function after a usage has been made illegal. The only 'history rewriting' that happens is if a function is emitted before it has been converted to a multiversion'ed function, at which point its name needs to be changed. Function templates and virtual functions are NOT yet supported (not supported in GCC either). Additionally, constructors/destructors are disallowed, but the former is planned. llvm-svn: 322028
* Fix TLS support check for Darwin 32-bit simulator targets.Volodymyr Sapsai2018-01-051-9/+15
| | | | | | | | | | | | | | | | | Also instead of checking architecture explicitly, use recently added "simulator" environment in the triple. rdar://problem/35083787 Reviewers: arphaman, bob.wilson Reviewed By: arphaman Subscribers: gparker42, cfe-commits Differential Revision: https://reviews.llvm.org/D41750 llvm-svn: 321890
* Reapply r321781: [Modules] Allow modules specified by -fmodule-map-file to ↵Bruno Cardoso Lopes2018-01-051-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | shadow implicitly found ones When modules come from module map files explicitly specified by -fmodule-map-file= arguments, allow those to override/shadow modules with the same name that are found implicitly by header search. If such a module is looked up by name (e.g. @import), we will always find the one from -fmodule-map-file. If we try to use a shadowed module by including one of its headers report an error. This enables developers to force use of a specific copy of their module to be used if there are multiple copies that would otherwise be visible, for example if they develop modules that are installed in the default search paths. Patch originally by Ben Langmuir, http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html Based on cfe-dev discussion: http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html Differential Revision: https://reviews.llvm.org/D31269 rdar://problem/23612102 llvm-svn: 321855
* Revert "[Modules] Allow modules specified by -fmodule-map-file to shadow ↵Bruno Cardoso Lopes2018-01-041-6/+1
| | | | | | | | | | | implicitly found ones" This reverts r321781 until I fix the leaks pointed out by bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12146 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/3741 llvm-svn: 321786
* [Modules] Allow modules specified by -fmodule-map-file to shadow implicitly ↵Bruno Cardoso Lopes2018-01-041-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | found ones When modules come from module map files explicitly specified by -fmodule-map-file= arguments, allow those to override/shadow modules with the same name that are found implicitly by header search. If such a module is looked up by name (e.g. @import), we will always find the one from -fmodule-map-file. If we try to use a shadowed module by including one of its headers report an error. This enables developers to force use of a specific copy of their module to be used if there are multiple copies that would otherwise be visible, for example if they develop modules that are installed in the default search paths. Patch originally by Ben Langmuir, http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html Based on cfe-dev discussion: http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html Differential Revision: https://reviews.llvm.org/D31269 rdar://problem/23612102 llvm-svn: 321781
* [OpenMP] Initial implementation of code generation for pragma 'target teams ↵Carlo Bertolli2018-01-031-1/+5
| | | | | | | | | | distribute parallel for' on host https://reviews.llvm.org/D41709 This patch includes code generation and testing for offloading when target device is host. llvm-svn: 321759
* Revert r321504 "[X86] Don't accidentally enable PKU on cannon lake and ↵Craig Topper2017-12-291-5/+2
| | | | | | | | | | | | | | icelake or CLWB on cannonlake." I based that commit on what was in Intel's public documentation here https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf Which specifically said CLWB wasn't until Icelake. But I've since cross checked with SDE and it thinks these features exist on CNL and ICL. So now I don't know what to believe. I've added test coverage of the current behavior as part of the revert so at least now have proof of what we're doing. llvm-svn: 321547
* Avoid int to string conversion in Twine or raw_ostream contexts.Benjamin Kramer2017-12-282-5/+5
| | | | | | Some output changes from uppercase hex to lowercase hex, no other functionality change intended. llvm-svn: 321526
* [X86] Don't accidentally enable PKU on cannon lake and icelake or CLWB on ↵Craig Topper2017-12-271-2/+4
| | | | | | | | cannonlake. We have cannonlake and icelake inheriting from skylake server in a switch using fallthroughs. But they aren't perfect supersets of skylake server. llvm-svn: 321504
* [X86] Enable avx512vpopcntdq and clwb for icelake.Craig Topper2017-12-271-1/+2
| | | | | | Per table 1-1 of the October 2017 edition of Intel® Architecture Instruction Set Extensions and Future Features Programming Reference llvm-svn: 321502
OpenPOWER on IntegriCloud