mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 04:02:41 +01:00
c48cf33847
Summary: In NEON, the immediate forms of VBIC and VORR are each represented as a single MC instruction, which takes its immediate operand already encoded in a NEON-friendly format: 8 data bits, plus some control bits indicating how to expand them into a full vector. In MVE, we represented immediate VBIC and VORR as four separate MC instructions each, for an 8-bit immediate shifted left by 0, 8, 16 or 24 bits. For each one, the value of the immediate operand is in the 'natural' form, i.e. the numerical value that would actually be BICed or ORRed into each vector lane (and also the same value shown in assembly). For example, MVE_VBICIZ16v4i32 takes an operand such as 0xab0000, which NEON would represent as 0xab | (control bits << 8). The MVE approach is superficially nice (it makes assembly input and output easy, and it's also nice if you're manually constructing immediate VBICs). But it turns out that it's better for isel if we make the NEON and MVE instructions work the same, because the ARMISD::VBICIMM and VORRIMM node types already encode their immediate into the NEON format, so it's easier if we can just use it. Also, this commit reduces the total amount of code rather than increasing it, which is surely an indication that it really is simpler to do it this way! Reviewers: dmgreen, ostannard, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73205 |
||
|---|---|---|
| .. | ||
| AArch64 | ||
| ARM | ||
| PowerPC | ||
| WebAssembly | ||
| X86 | ||
| CMakeLists.txt | ||