forked from OSchip/llvm-project
833550fc74
256-bit horizontal math ops are an x86 monstrosity (and thankfully have not been extended to 512-bit AFAIK). The two 128-bit halves operate on separate halves of the inputs. So if we don't demand anything in the upper half of the result, we can extract the low halves of the inputs, do the math, and then insert that result into a 256-bit output. All of the extract/insert is free (ymm<-->xmm), so we're left with a narrower (cheaper) version of the original op. In the affected tests based on: https://bugs.llvm.org/show_bug.cgi?id=33758 https://bugs.llvm.org/show_bug.cgi?id=38971 ...we see that the h-op narrowing can result in further narrowing of other math via existing generic transforms. I originally drafted this patch as an exact pattern match starting from extract_vector_elt, but I thought we might see diffs starting from extract_subvector too, so I changed it to a more general demanded elements solution. There are no extra existing regression test improvements from that switch though, so we could go back. Differential Revision: https://reviews.llvm.org/D57841 llvm-svn: 353641 |
||
|---|---|---|
| .. | ||
| AArch64 | ||
| AMDGPU | ||
| ARC | ||
| ARM | ||
| AVR | ||
| BPF | ||
| Generic | ||
| Hexagon | ||
| Inputs | ||
| Lanai | ||
| MIR | ||
| MSP430 | ||
| Mips | ||
| NVPTX | ||
| PowerPC | ||
| RISCV | ||
| SPARC | ||
| SystemZ | ||
| Thumb | ||
| Thumb2 | ||
| WebAssembly | ||
| WinCFGuard | ||
| WinEH | ||
| X86 | ||
| XCore | ||