aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2019-02-10 15:22:06 +0000
committerSanjay Patel <spatel@rotateright.com>2019-02-10 15:22:06 +0000
commit833550fc74b9d860ba8a711df2d1e3855f91bce1 (patch)
tree5dc3a3ec38d3edda98fe6312106eca3763c884c0 /llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
parent76683e7b5800abd0b194bfb93ae8c85c60581665 (diff)
downloadllvm-833550fc74b9d860ba8a711df2d1e3855f91bce1.zip
llvm-833550fc74b9d860ba8a711df2d1e3855f91bce1.tar.gz
llvm-833550fc74b9d860ba8a711df2d1e3855f91bce1.tar.bz2
[x86] narrow 256-bit horizontal ops via demanded elements
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
Diffstat (limited to 'llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp')
0 files changed, 0 insertions, 0 deletions