summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
diff options
context:
space:
mode:
authorRoman Lebedev <lebedev.ri@gmail.com>2019-02-04 19:04:26 +0000
committerRoman Lebedev <lebedev.ri@gmail.com>2019-02-04 19:04:26 +0000
commitb7ecc9b6241b9580ce7c4972e8514f2367a6f49d (patch)
treeb126f2b7e5eec1d704f5be09897253e692b797d3 /llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
parentb3e86709dc76afac082bd3c7ed4c90ef9847f7b5 (diff)
downloadbcm5719-llvm-b7ecc9b6241b9580ce7c4972e8514f2367a6f49d.tar.gz
bcm5719-llvm-b7ecc9b6241b9580ce7c4972e8514f2367a6f49d.zip
[X86] X86DAGToDAGISel::matchBitExtract(): prepare 'control' in 32 bits
Summary: Noticed while looking at D56052. ``` // The 'control' of BEXTR has the pattern of: // [15...8 bit][ 7...0 bit] location // [ bit count][ shift] name // I.e. 0b000000011'00000001 means (x >> 0b1) & 0b11 ``` I.e. we do not care about any of the bits aside from the low 16 bits. So there is no point in doing the `slh`,`or` in 64 bits, let's just do everything in 32 bits, and anyext if needed. We could do that in 16 even, but we intentionally don't zext to i16 (longer encoding IIRC), so i'm guessing the same applies here. Reviewers: craig.topper, andreadb, RKSimon Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D56715 llvm-svn: 353073
Diffstat (limited to 'llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud