[llvm-commits] [Patch] Switch-to-lookup tables: do simple constant propagation

[Sean Silva]

> If a lookup table isn't formed, it may also be useful to merge blocks to
> create a subtract(or some similar calculation) even it wasn't written in the
> code? So maybe we could splits the blocks and then recombine them if lookup

This is kind of the "tip of the iceberg" for a lot of different kinds
of simplifications. Once we start replacing cases with a "closed form"
such as subtraction, that opens the door to more generally replace
manually specified case->val mappings with a closed form. I don't
think there has been any research into this, but an interesting
question is for how many of these switch mappings can the mapping be
computed in <=N (say, 3) {add,sub,xor,shl,shr} instructions. Or, say,
taking a switch like:

switch (n) {
case 13: return 4;
case 19: return 3;
case 17: return 2;
default: unreachable();
}

and turning it into popcnt(n) + ((n&4) >> 2). I'm not sure it would
pay off in this small switch, but if there are 20 cases it probably
would help a great deal.

Intel's new PEXT instruction also opens up the door to completely
different kinds of fast mappings (and I'm sure every target has its
own fancy instructions that can be handy for different kinds of fast
mappings).

A lot of this stuff is more likely to be interesting to a
superoptimizer and not a general optimizer, but there might be some
simple kinds of transformations that can be tried quickly and that pay
off often-enough to be worth using (even something as simple as adding
an offset to the keys to make them a denser set of integers 0-N
instead of 15-(N+15) might enable more table conversions and/or make
tables smaller).

--Sean Silva

On Wed, Oct 3, 2012 at 12:34 PM, Craig Topper <craig.topper at gmail.com> wrote:
> If a lookup table isn't formed, it may also be useful to merge blocks to
> create a subtract(or some similar calculation) even it wasn't written in the
> code? So maybe we could splits the blocks and then recombine them if lookup
> table doesn't work?
>
>
> On Wed, Oct 3, 2012 at 5:39 AM, Hans Wennborg <hans at chromium.org> wrote:
>>
>> On Wed, Oct 3, 2012 at 12:51 PM, Duncan Sands <baldrick at free.fr> wrote:
>> > Hi Hans,
>> >
>> >
>> >> A patch [1] by Craig earlier this week pointed out that Clang fails to
>> >> build lookup tables for switches like this:
>> >>
>> >>    switch(x) {
>> >>      case 1: return 5;
>> >>      case 2: return 42;
>> >>      case 3: case 4: case 5:
>> >>        return x - 123;
>> >>      default: return 123;
>> >>    }
>> >>
>> >> Where the resulting value for the 3, 4, 5 cases is "x - 123", rather
>> >> than a constant.
>> >
>> >
>> > maybe it is better to do this as part of some more generic switch
>> > simplification
>> > logic rather than during table construction.
>>
>> That would mean cloning the basic block with "return x - 123" into one
>> block for each case, and then constant propagation could take care of
>> it. Or rather, we should only clone it if it can get constant folded.
>>
>> Would that always be profitable, though? If the switch doesn't get
>> turned into a lookup table, we've replaced one basic block with lots
>> of small ones. At least for code size, it seems that could be counter
>> productive?
>>
>> Thanks,
>> Hans
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
>
> --
> ~Craig
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>