aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/X86/Disassembler/X86Disassembler.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-07-08[llvm] annotate interfaces in llvm-c for DLL export (#141701)Andrew Rogers1-0/+1
## Purpose This patch is one in a series of code-mods that annotate LLVM’s public interface for export. This patch annotates the `llvm-c` interface with a new `LLVM_C_ABI` annotation, which behaves like the `LLVM_ABI`. This annotation currently has no meaningful impact on the LLVM build; however, it is a prerequisite to support an LLVM Windows DLL (shared library) build. ## Overview 1. Add a new `llvm-c/Visibility.h` header file that defines a new `LLVM_C_ABI` macro. The macro resolves to the proper DLL export/import annotation on Windows and a "default" visibility annotation elsewhere. 2. Add a new `LLVM_ENABLE_LLVM_C_EXPORT_ANNOTATIONS` `#cmakedefine` that is used to gate the definition of `LLVM_C_ABI`. 3. Remove the existing `LLVM_C_ABI` definition from `llvm/Support/Compiler.h`. Update the small number of `LLVM_C_ABI` references to get it from the new `llvm-c/Visibility.h` header. 4. Code-mod annotate the public `llvm-c` interface using the [Interface Definition Scanner (IDS)](https://github.com/compnerd/ids) tool. 5. Format the changes with `clang-format`. ## Background This effort is tracked in #109483. Additional context is provided in [this discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307), and documentation for `LLVM_ABI` and related annotations is found in the LLVM repo [here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst). ## Validation Local builds and tests to validate cross-platform compatibility. This included llvm, clang, and lldb on the following configurations: - Windows with MSVC - Windows with Clang - Linux with GCC - Linux with Clang - Darwin with Clang
2025-03-21Revert "[X86][AVX10.2] Support YMM rounding new instructions (#101825)" ↵Phoebe Wang1-1/+1
(#132362) This reverts commit 0dba5381d8c8e4cadc32a067bf2fe5e3486ae53d. YMM rounding was removed from AVX10 whitepaper. Ref: https://cdrdv2.intel.com/v1/dl/getContent/784343 The MINMAX and SATURATING CONVERT instructions will be removed as a follow up.
2024-11-22[X86] Ignore REX prefixes not immediately before opcode (#117299)Aiden Grossman1-5/+8
The Intel X86 Architecture Manual says the following: > A REX prefix is ignored, as are its individual bits, when it is not needed > for an instruction or when it does not immediately precede the opcode byte or > the escape opcode byte (0FH) of an instruction for which it is needed. This > has the implication that only one REX prefix, properly located, can affect an > instruction. We currently do not handle these cases in the disassembler, leading to incorrect disassembly. This patch rectifies the situation by treating REX prefixes as standard prefixes rather than only expecting them before the Opcode. The motivating test case added as a test was fuzzer generated.
2024-11-07[X86] Switch to the new symbol visibility macros (#109982)Thomas Fransham1-1/+1
Switch LLVMInitialize* functions to new the symbol visibility macros that will work for windows. This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on windows.
2024-11-01[X86][AMX] Support AMX-TRANSPOSE (#113532)Phoebe Wang1-0/+5
Ref.: https://cdrdv2.intel.com/v1/dl/getContent/671368
2024-08-04[X86][AVX10.2] Support YMM rounding new instructions (#101825)Phoebe Wang1-1/+1
Ref.: https://cdrdv2.intel.com/v1/dl/getContent/828965
2024-08-03Reland "[X86][AVX10.2] Support AVX10.2 option and VMPSADBW/VADDP[D,H,S] new ↵Phoebe Wang1-3/+7
instructions (#101452)" (#101616) Ref.: https://cdrdv2.intel.com/v1/dl/getContent/828965
2024-08-02Revert "[X86][AVX10.2] Support AVX10.2 option and VMPSADBW/VADDP[D,H,S] new ↵Phoebe Wang1-8/+4
instructions" (#101612) Reverts llvm/llvm-project#101452 There are several buildbot failed. Revert first.
2024-08-02[X86][AVX10.2] Support AVX10.2 option and VMPSADBW/VADDP[D,H,S] new ↵Phoebe Wang1-4/+8
instructions (#101452) Ref.: https://cdrdv2.intel.com/v1/dl/getContent/828965
2024-06-13[X86][MC] Not decode 0xf3 as rep prefix if it's right before REX2Shengchen Kan1-1/+4
This fixes https://github.com/llvm/llvm-project/issues/95412
2024-03-08[X86][MC] Support encoding/decoding for APX CCMP/CTEST (#83863)Shengchen Kan1-4/+39
APX assembly syntax recommendations: https://cdrdv2.intel.com/v1/dl/getContent/817241 NOTE: The change in llvm/tools/llvm-exegesis/lib/X86/Target.cpp is for test LLVM :: tools/llvm-exegesis/X86/latency/latency-SETCCr-cond-codes-sweep.s For `SETcc`, llvm-exegesis would randomly choose 1 other instruction to test with `SETcc`, after selecting the instruction, llvm-exegesis would check if the operand is initialized and valid, if not `randomizeTargetMCOperand` would choose a value for invalid operand, it misses support for condition code operand, which cause the flaky failure after `CCMP` supported. llvm-exegesis can choose `CCMP` without specifying ccmp feature b/c it use `MCSubtarget` and only16/32/64 bit is considered. llvm-exegesis doesn't choose other instructions b/c requirement in `hasAliasingRegistersThrough`: the instruction should use GPR (defined by `SETcc`) and define `EFLAGS` (used by `SETcc`).
2024-02-23[X86][MC] Reject out-of-range control and debug registers encoded with APX ↵Timothy Herchen1-0/+4
(#82584) Fixes #82557. APX specification states that the high bits found in REX2 used to encode GPRs can also be used to encode control and debug registers, although all of them will #UD. Therefore, when disassembling we reject attempts to create control or debug registers with a value of 16 or more. See page 22 of the [specification](https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html): > Note that the R, X and B register identifiers can also address non-GPR register types, such as vector registers, control registers and debug registers. When any of them does, the highest-order bits REX2.R4, REX2.X4 or REX2.B4 are generally ignored, except when the register being addressed is a control or debug register. [...] The exception is that REX2.R4 and REX2.R3 [*sic*] are not ignored when the R register identifier addresses a control or debug register. Furthermore, if any attempt is made to access a non-existent control register (CR*) or debug register (DR*) using the REX2 prefix and one of the following instructions: “MOV CR*, r64”, “MOV r64, CR*”, “MOV DR*, r64”, “MOV r64, DR*”. #UD is raised. The invalid encodings are 64-bit only because `0xd5` is a valid instruction in 32-bit mode.
2024-01-26[X86] Support promoted ENQCMD, KEYLOCKER and USERMSR (#77293)XinWang101-0/+3
R16-R31 was added into GPRs in https://github.com/llvm/llvm-project/pull/70958, This patch supports the promoted ENQCMD, KEYLOCKER and USER-MSR instructions in EVEX space. RFC: https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4
2024-01-25[X86][MC] Support Enc/Dec for NF BMI instructions (#76709)XinWang101-3/+22
Promoted BMI instructions were supported in #73899
2023-12-28[X86][MC] Support encoding/decoding for APX variant ↵Shengchen Kan1-1/+5
ADD/SUB/ADC/SBB/OR/XOR/NEG/NOT instructions (#76319) Four variants: promoted legacy, ND (new data destination), NF (no flags update) and NF_ND (NF + ND). The syntax of NF instructions is aligned with GNU binutils. https://sourceware.org/pipermail/binutils/2023-September/129545.html
2023-12-15[X86][MC] Support Enc/Dec for EGPR for promoted MOVDIR instruction (#74713)XinWang101-1/+2
R16-R31 was added into GPRs in https://github.com/llvm/llvm-project/pull/70958, This patch supports the encoding/decoding for promoted MOVDIR instruction in EVEX space. RFC: https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4
2023-11-24[X86][MC] Support encoding/decoding for PUSH2[P]/POP2[P] (#73233)Shengchen Kan1-0/+9
PUSH2 and POP2 are two new instructions for (respectively) pushing/popping 2 GPRs at a time to/from the stack. The opcodes of PUSH2 and POP2 are those of “PUSH r/m” and “POP r/m” from legacy map 0, but we require ModRM.Mod = 3 in order to disallow memory operand. The 1-bit Push-Pop Acceleration hint described in #73092 applies to PUSH2/POP2 too, then we have PUSH2P/POP2P. For AT&T syntax, PUSH2[P] pushes the registers from right to left onto the stack. POP2[P] pops the stack to registers from right to left. Intel syntax has the opposite order - from left to right. The assembly syntax is aligned with GCC & binutils https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637718.html
2023-11-23[X86][MC] Support encoding/decoding for PUSHP/POPP (#73092)Shengchen Kan1-2/+2
A PUSH and its corresponding POP may be marked with a 1-bit Push-Pop Acceleration (PPX) hint to indicate that the POP reads the value written by the PUSH from the stack. The PPX hint is encoded by setting REX2.W = 1 and is applicable only to PUSH with opcode 0x50+rd and POP with opcode 0x58+rd in the legacy space. It is not applicable to any other variants of PUSH and POP.
2023-11-22[X86][MC] Support encoding/decoding for JMPABS (#72835)Shengchen Kan1-0/+5
JMPABS is a 64-bit only ISA extension, and acts as a near-direct branch with an absolute target. The 64-bit immediate operand is treated an as absolute effective address, which is subject to canonicality checks. It is in legacy map 0 and requires REX2 prefix with `REX2.M0=0` and `REX2.W=0`. All other REX2 payload bits are ignored. blog: https://kanrobert.github.io/rfc/All-about-APX-JMPABS/ This patch 1. Extends `ExplicitVEXPrefix` to `ExplicitOpPrefix` for instrcutions requires explicit `REX2` or `EVEX` 2. Adds `ATTR_REX2` and `IC_64BIT_REX2` to put `JMPABS` , `MOV EAX, moffs32` in different tables to avoid opcode conflict NOTE: 1. `ExplicitREX2Prefix` can be reused by the following PUSHP/POPP instructions. 2. `ExplicitEVEXPrefix` will be used by the instructions promoted to EVEX space for EGPR.
2023-11-15[X86][MC] Support decoding of EGPR for APX (#72102)Shengchen Kan1-42/+84
https://github.com/llvm/llvm-project/pull/70958 adds registers R16-R31 (EGPR), this patch 1. Supports decoding of EGPR for instruction w/ REX2 prefix 2. Supports decoding of EGPR for instruction w/ EVEX prefix For simplicity's sake, we 1. Simulate the REX prefix w/ the 1st payload of REX2 2. Simulate the REX2 prefix w/ the 2nd and 3rd payloads of EVEX RFC: https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4 Explanations for some changes: 1. invalid-EVEX-R2.txt is deleted b/c `0x62 0xe1 0xff 0x08 0x79 0xc0` is valid and decoded to `vcvtsd2usi %xmm0, %r16` now. 2. One line in x86-64-err.txt is removed b/c APX relaxes the limitation of the 1st and 2nd payloads of EVEX prefix, so the error message changes
2023-10-16[X86] Add USER_MSR instructions. (#68944)Freddy Ye1-0/+9
For more details about this instruction, please refer to the latest ISE document: https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
2023-10-12Use llvm::endianness::{big,little,native} (NFC)Kazu Hirata1-1/+1
Note that llvm::support::endianness has been renamed to llvm::endianness while becoming an enum class as opposed to an enum. This patch replaces support::{big,little,native} with llvm::endianness::{big,little,native}.
2023-01-08[X86][Disassembler][NFCI] Read bytes with support::endian::readBenjamin Kramer1-4/+1
2022-08-08[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song1-1/+1
With C++17 there is no Clang pedantic warning or MSVC C5051.
2022-06-13[X86][Disassembler] Fix displacement operand size for symbolizerMaksim Panchenko1-2/+1
On 64-bit X86, 0x66 operand-size override prefix will change the size of the instruction operand, e.g. from 32 bits to 16 bits, but it will not modify the size of the displacement operand used for memory addressing, which will always be 32 bits. Reviewed By: skan, rafauler Differential Revision: https://reviews.llvm.org/D126726
2022-05-25[MCDisassembler] Disambiguate Size parameter in tryAddingSymbolicOperand()Maksim Panchenko1-8/+10
MCSymbolizer::tryAddingSymbolicOperand() overloaded the Size parameter to specify either the instruction size or the operand size depending on the architecture. However, for proper symbolic disassembly on X86, we need to know both sizes, as an instruction can have two operands, and the instruction size cannot be reliably calculated based on the operand offset and its size. Hence, split Size into OpSize and InstSize. For X86, the new interface allows to fix a couple of issues: * Correctly adjust the value of PC-relative operands. * Set operand size to zero when the operand is specified implicitly. Differential Revision: https://reviews.llvm.org/D126101
2022-03-21[X86][NFCI] Remove redundant functionsMaksim Panchenko1-49/+9
Reviewed By: skan Differential Revision: https://reviews.llvm.org/D121731
2022-03-17[X86] Rename more target feature related things consistency. NFCCraig Topper1-3/+3
-Rename Mode*Bit to Is*Bit to match X86Subtarget. -Rename FeatureLAHFSAHF to FeatureLAFHSAFH64 to match X86Subtarget. -Use consistent capitalization Reviewed By: skan Differential Revision: https://reviews.llvm.org/D121975
2022-03-07Revert "[X86] Fix MCSymbolizer interface for X86Disassembler"Maksim Panchenko1-16/+15
This reverts commit 0c2b43ab8cb1067dd1c7899094b824890803a7d2.
2022-03-07[X86] Fix MCSymbolizer interface for X86DisassemblerMaksim Panchenko1-15/+16
Fix a number of issues with MCSymbolizer::tryAddingSymbolicOperand() in X86Disassembler: * Pass instruction size instead of immediate size. * Correctly adjust the value of PC-relative operands. * Set operand offset to zero when the operand is specified implicitly. Reviewed By: Amir, skan Differential Revision: https://reviews.llvm.org/D121065
2021-10-12[X86] Remove little support we had for MPXFangrui Song1-4/+0
GCC 9.1 removed Intel MPX support. Linux kernel removed MPX in 2019. glibc 2.35 will remove MPX. Our support is limited: we support assembling of bndmov but not bnd. Just remove it. Reviewed By: pengfei, skan Differential Revision: https://reviews.llvm.org/D111517
2021-10-08Move TargetRegistry.(h|cpp) from Support to MCReid Kleckner1-1/+1
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support. This allows us to ensure that Support doesn't have includes from MC/*. Differential Revision: https://reviews.llvm.org/D111454
2021-08-10[X86] AVX512FP16 instructions enabling 1/6Wang, Pengfei1-4/+28
1. Enable FP16 type support and basic declarations used by following patches. 2. Enable new instructions VMOVW and VMOVSH. Ref.: https://software.intel.com/content/www/us/en/develop/download/intel-avx512-fp16-architecture-specification.html Reviewed By: LuoYuanke Differential Revision: https://reviews.llvm.org/D105263
2021-07-15[X86] Fix handling of maskmovdqu in X32Harald van Dijk1-0/+4
The maskmovdqu instruction is an odd one: it has a 32-bit and a 64-bit variant, the former using EDI, the latter RDI, but the use of the register is implicit. In 64-bit mode, a 0x67 prefix can be used to get the version using EDI, but there is no way to express this in assembly in a single instruction, the only way is with an explicit addr32. This change adds support for the instruction. When generating assembly text, that explicit addr32 will be added. When not generating assembly text, it will be kept as a single instruction and will be emitted with that 0x67 prefix. When parsing assembly text, it will be re-parsed as ADDR32 followed by MASKMOVDQU64, which still results in the correct bytes when converted to machine code. The same applies to vmaskmovdqu as well. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D103427
2021-02-02[X86] Fix disassembly of x86-64 GDTLS code sequenceAndrew Ng1-0/+1
For x86-64 the REX.w prefix takes precedence over any other size override (i.e. 0x66). Therefore, for x86-64 when REX.w is present set 'hasOpSize' to false to ensure that any size override is ignored. Fixes PR48901. Differential Revision: https://reviews.llvm.org/D95682
2020-09-22[X86] Add missing namespace closure comments. NFCI.Simon Pilgrim1-3/+3
Fixes some clang-tidy llvm-namespace-comment warnings.
2020-07-03[X86] Remove MODRM_SPLITREGM from the disassembler tables.Craig Topper1-3/+0
This offers a very minor table size reduction due to only being used for one AMX opcode.
2020-07-02[X86-64] Support Intel AMX instructionsXiang1 Zhang1-6/+30
Summary: INTEL ADVANCED MATRIX EXTENSIONS (AMX). AMX is a new programming paradigm, it has a set of 2-dimensional registers (TILES) representing sub-arrays from a larger 2-dimensional memory image and operate on TILES. Spec can be found in Chapter 3 here https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html Reviewers: LuoYuanke, annita.zhang, pengfei, RKSimon, xiangzhangllvm Reviewed By: xiangzhangllvm Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82705
2020-01-14CMake: Make most target symbols hidden by defaultTom Stellard1-1/+1
Summary: For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF this change makes all symbols in the target specific libraries hidden by default. A new macro called LLVM_EXTERNAL_VISIBILITY has been added to mark symbols in these libraries public, which is mainly needed for the definitions of the LLVMInitialize* functions. This patch reduces the number of public symbols in libLLVM.so by about 25%. This should improve load times for the dynamic library and also make abi checker tools, like abidiff require less memory when analyzing libLLVM.so One side-effect of this change is that for builds with LLVM_BUILD_LLVM_DYLIB=ON and LLVM_LINK_LLVM_DYLIB=ON some unittests that access symbols that are no longer public will need to be statically linked. Before and after public symbol counts (using gcc 8.2.1, ld.bfd 2.31.1): nm before/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 36221 nm after/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 26278 Reviewers: chandlerc, beanz, mgorny, rnk, hans Reviewed By: rnk, hans Subscribers: merge_guards_bot, luismarques, smeenai, ldionne, lenary, s.egerton, pzheng, sameer.abuasal, MaskRay, wuzish, echristo, Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, kristina, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D54439
2020-01-13[X86][Disassembler] Fix a bug when disassembling an empty stringFangrui Song1-1/+3
readPrefixes() assumes insn->bytes is non-empty. The code path is not exercised in llvm-mc because llvm-mc does not feed empty input to MCDisassembler::getInstruction(). This bug is uncovered by a5994c789a2982a770254ae1607b5b4cb641f73c. An empty string did not crash before because the deleted regionReader() allowed UINT64_C(-1) as insn->readerCursor. Bytes.size() <= Address -> R->Base 0 <= UINT64_C(-1) - UINT32_C(-1)
2020-01-13[X86] Fix MSVC "truncation from 'int' to 'bool'" warning. NFCI.Simon Pilgrim1-2/+2
2020-01-12[X86][Disassembler] Merge X86DisassemblerDecoder.cpp into ↵Fangrui Song1-35/+1569
X86Disassembler.cpp and refactor
2020-01-12[X86][Disassembler] SimplifyFangrui Song1-6/+0
2020-01-11[X86][Disassembler] Optimize argument passing and immediate readingFangrui Song1-15/+17
2020-01-11[Disassembler] Delete the VStream parameter of MCDisassembler::getInstruction()Fangrui Song1-2/+1
The argument is llvm::null() everywhere except llvm::errs() in llvm-objdump in -DLLVM_ENABLE_ASSERTIONS=On builds. It is used by no target but X86 in -DLLVM_ENABLE_ASSERTIONS=On builds. If we ever have the needs to add verbose log to disassemblers, we can record log with a member function, instead of passing it around as an argument.
2020-01-11[X86][Disassembler] Replace custom logger with LLVM_DEBUGFangrui Song1-27/+2
llvm-objdump -d on clang is decreased from 7.8s to 7.4s. The improvement is likely due to the elimination of logger setup and dbgprintf(), which has a large overhead.
2020-01-11[X86][Disassembler] Simplify and optimize reader functionsFangrui Song1-20/+2
llvm-objdump -d on clang is decreased from 8.2s to 7.8s.
2019-06-11Revert CMake: Make most target symbols hidden by defaultTom Stellard1-1/+1
This reverts r362990 (git commit 374571301dc8e9bc9fdd1d70f86015de198673bd) This was causing linker warnings on Darwin: ld: warning: direct access in function 'llvm::initializeEvexToVexInstPassPass(llvm::PassRegistry&)' from file '../../lib/libLLVMX86CodeGen.a(X86EvexToVex.cpp.o)' to global weak symbol 'void std::__1::__call_once_proxy<std::__1::tuple<void* (&)(llvm::PassRegistry&), std::__1::reference_wrapper<llvm::PassRegistry>&&> >(void*)' from file '../../lib/libLLVMCore.a(Verifier.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. llvm-svn: 363028
2019-06-10CMake: Make most target symbols hidden by defaultTom Stellard1-1/+1
Summary: For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF this change makes all symbols in the target specific libraries hidden by default. A new macro called LLVM_EXTERNAL_VISIBILITY has been added to mark symbols in these libraries public, which is mainly needed for the definitions of the LLVMInitialize* functions. This patch reduces the number of public symbols in libLLVM.so by about 25%. This should improve load times for the dynamic library and also make abi checker tools, like abidiff require less memory when analyzing libLLVM.so One side-effect of this change is that for builds with LLVM_BUILD_LLVM_DYLIB=ON and LLVM_LINK_LLVM_DYLIB=ON some unittests that access symbols that are no longer public will need to be statically linked. Before and after public symbol counts (using gcc 8.2.1, ld.bfd 2.31.1): nm before/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 36221 nm after/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 26278 Reviewers: chandlerc, beanz, mgorny, rnk, hans Reviewed By: rnk, hans Subscribers: Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, kristina, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D54439 llvm-svn: 362990
2019-05-31[X86] Add VP2INTERSECT instructionsPengfei Wang1-0/+1
Support Intel AVX512 VP2INTERSECT instructions in llvm Patch by Xiang Zhang (xiangzhangllvm) Differential Revision: https://reviews.llvm.org/D62366 llvm-svn: 362188
generated by cgit v1.1 at 2025-09-29 04:17:26 +0000