[PATCH] D30416: [InstCombine] Redo reduceLoadOpStoreWidth in instcombine for bitfield store optimization.

[Wei Mi via llvm-commits]

After looking at the benchmark motivating the test, I find it is much
harder for codegenprepare to catch all the shrinking opportunities compared
with instcombine, because of two things:

* loadpre may merge the original load in a shrinking pattern with other
load in a very early position, and there maybe other stores in between. The
safety check for the codegenprepare now simply scan mayWriteToMemory insns
between load and store in the candidate shrinking pattern, and it will fail
because of those stores in between.

* we may see the following pattern. a.f1 is a bitfield. Ideally, we should
do the shrinking for all the three stores. But codegenprepare works in
top-down order. After the first store is shrinked, it is hard for the
second and the third to know %bf.set is the same as the value loaded from
%0. If we do this in instcombine, it is much easier because before
load/store elimination, %bf.set will be loaded from %0 respecitively in
if.then9 and in if.end41.

entry:
  %0 = bitcast %class.B* %this to i64*
  %bf.load = load i64, i64* %0, align 8
  %dec = add i64 %bf.load, 65535
  %bf.value = and i64 %dec, 65535
  %bf.clear5 = and i64 %bf.load, -65536
  %bf.set = or i64 %bf.value, %bf.clear5
  store i64 %bf.set, i64* %0, align 8
  ...
if.then9:
  %inc79 = add i64 %bf.set, 281474976710656       // we hope to know
%bf.set is the same as load i64, i64* %0, align 8.
  %bf.shl = and i64 %inc79, 71776119061217280
  %bf.clear18 = and i64 %bf.set, -71776119061217281
  %bf.set19 = or i64 %bf.shl, %bf.clear18
  store i64 %bf.set19, i64* %0, align 8
  ...
if.end41:
  %inc4578 = add i64 %bf.set, 65536                       // we hope to
know %bf.set is the same as load i64, i64* %0, align 8.
  %bf.shl48 = and i64 %inc4578, 4294901760
  %bf.clear49 = and i64 %bf.set, -4294901761
  %bf.set50 = or i64 %bf.shl48, %bf.clear49
  store i64 %bf.set50, i64* %0, align 8

There are two types of shrinking in the patch now: 1. shrinking without
orginal load. 2. shrinking with original load -- shrinking illegal type to
legal type (handling test from test/CodeGen/ARM/illegal-bitfield-loadstore.ll).
Since the second type shrinking may need TargetLowering information and
better stay in CodeGenPrepare, I intend to split the first type shrinking
and put it into instcombine, so that part of shrinking can be more useful
than staying in CodeGenPrepare.

Thanks,
Wei.


On Sat, Mar 4, 2017 at 12:49 PM, Wei Mi via Phabricator <
reviews at reviews.llvm.org> wrote:

> wmi added a comment.
>
> Although I did't find regression in internal benchmarks testing, I still
> moved the transformation to codegenprepare because we want to use
> TargetLowering information to decide how to shrink in some cases.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D30416
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170306/7962d44b/attachment.html>