[PATCH] D47113: [CVP] Teach CorrelatedValuePropagation to reduce the width of lshr instruction.

[Dave Green via Phabricator via llvm-commits]

dmgreen added a comment.

Sorry, I forgot to mention the important fact that those results were Arm, specifically thumbv8m.baseline on a cortex-m23 (where the pointers are 32bit, and only i32 are legal types). Try this data layout for arm code:
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"

This should show the extra And node being added (although in this case it won't lead to different assembly I believe, just larger IR. isel can remove the And).
https://godbolt.org/g/xjmSPn

The tests I ran above were embedded benchmarks on microcontroller cpus. They are quick and easy enough to run as they tend to contain no noise. The ones that went down were mostly thumb-1 only cores, but the cortex-m7 also showed decreases on the same test. The extra tests I've ran now are a your more standard set of linux benchmarks on cortex-a cores for both arm and aarch64 (spec, the llvm testsuite etc). The only thing that didn't look like noise was drop3 from the BitBench, which got better. Its doing some odd looking bit manipulation in a loop. Playing around a bit the score seems to go up or down depending on which parts of the loop are enabled.

As Sanjay found in http://lists.llvm.org/pipermail/llvm-dev/2018-January/120522.html, converting to illegal types can be beneficial if it leads to extra folds, but is difficult to tell when exactly it will make things better or worse. Reducing the type width from an i64 to an i32 is almost certainly a good thing to do on Arm, but reducing an i32 to an i8 isn't so cut-and-dry. The safe option here would be to only convert to legal types (or perhaps also reducing to types larger than the largest legal type. I'm not sure what that would do in the motivating case).


Repository:
  rL LLVM

https://reviews.llvm.org/D47113