aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/WasmObjectFile.cpp
diff options
context:
space:
mode:
authorNikita Popov <nikita.ppv@gmail.com>2021-04-24 16:18:56 +0200
committerNikita Popov <nikita.ppv@gmail.com>2021-05-10 22:22:39 +0200
commit463ea28e96c78f484d9ea44912d9bc70ff084c86 (patch)
tree2e23f6bcb8ea8591bdfaf0cd103a4c9ea8069fb5 /llvm/lib/Object/WasmObjectFile.cpp
parent93a9a8a8d90f5b9bb6965ebb1104082692d41833 (diff)
downloadllvm-463ea28e96c78f484d9ea44912d9bc70ff084c86.zip
llvm-463ea28e96c78f484d9ea44912d9bc70ff084c86.tar.gz
llvm-463ea28e96c78f484d9ea44912d9bc70ff084c86.tar.bz2
[InstCombine] Fold comparison of integers by parts
Let's say you represent (i32, i32) as an i64 from which the parts are extracted with lshr/trunc. Then, if you compare two tuples by parts you get something like A[0] == B[0] && A[1] == B[1], just that the part extraction happens by lshr/trunc and not a narrow load or similar. The fold implemented here reduces such equality comparisons by converting them into a comparison on a larger part of the integer (which might be the whole integer). It handles both the "and of eq" and the conjugated "or of ne" case. I'm being conservative with one-use for now, though this could be relaxed if profitable (the base pattern converts 11 instructions into 5 instructions, but there's quite a few variations on how it can play out). Differential Revision: https://reviews.llvm.org/D101232
Diffstat (limited to 'llvm/lib/Object/WasmObjectFile.cpp')
0 files changed, 0 insertions, 0 deletions