llvm dev - Nov 2021 - Missed optimization of bitwise expressions

> If we're missing 2 variable logic reductions, those are common/easy
enough that we should have those in instcombine.
I think I agree with this. There should be 16 canonical forms for the
bitwise functions on two variables, including degenerate cases like
"false" as well as the interesting ones like A&~B, ~A^B etc. It
seems
reasonable that we should be able to simplify AND OR and XOR on any
pair of canonical forms, and produce another canonical form as the
result.

For three variables there would be 256 canonical forms, which seems
far less tractable.

Jay.

On Thu, 11 Nov 2021 at 16:35, Sanjay Patel <spatel at rotateright.com>
wrote:
>
> Nice test program! I don't know python well enough to understand that
yet, but no reason to be ashamed of hacks. :)
>
> If we're missing 2 variable logic reductions, those are common/easy
enough that we should have those in instcombine. So yes, it would be great if
you file bugs for those, and they could be marked with the 'beginner'
keyword too as a potential easy patch for newcomers to LLVM.
>
> There's also a set of recent patch proposals for 3 variable logic
reductions -- for example, https://reviews.llvm.org/D112276 -- these were
inspired by a logic lookup table function as discussed in the comments.
> The extra-use and commuted variations make these harder. IMO, this is where
there should be a dedicated pass/solver for logic folds if we want those
optimizations to be complete. Otherwise, there's an explosion of possible
pattern match combinations.
>
>
> On Thu, Nov 11, 2021 at 6:34 AM Jay Foad <jay.foad at gmail.com>
wrote:
>>
>> Hi,
>>
>> I tried searching for small bitwise expressions using AND OR XOR and
>> NOT that "opt -O3" fails to optimize to a simpler form. For
example:
>>
>> (A^B)|~A --> ~(A&B)
>> https://alive2.llvm.org/ce/z/HpWfzp
>>
>> A|B|(A^B) --> A|B
>> https://alive2.llvm.org/ce/z/UCC6uM
>>
>> ((A|B)^C)&A --> A&~C (actually I don't understand why
this one is OK,
>> even if B might be poison, but alive2 says it is OK)
>> https://alive2.llvm.org/ce/z/mkvW6p
>>
>> I can file bugs for specific examples but I wondered if there was any
>> interest in a more systematic approach to finding these missed
>> optimizations? My approach was to write some very hacky Python
>> (https://gist.github.com/jayfoad/94f4c68fa3a9aa908db79dbd7e9df80d,
>> please don't read it) to exhaustively generate programs; then take
all
>> the programs with a given truth table, run them all through "opt
-O3",
>> and check that they all got optimized to the same (or at least equally
>> short) output.
>>
>> Thanks,
>> Jay.

For any number of inputs, you can build a look-up table (LUT).

Some processor architectures have LUT instructions.  For those, your built
LUT can be used directly.

Otherwise, for each of the 256 possible LUTs you can precompute the
"optimal" representation for the target. This may depend on what the
target
offers - e.g. some processors have an "and not" instruction that may
allow
a more compact sequence. For any of the 256 LUTs (and counterparts arising
from the permutation of inputs) you can cache the resulting target-mapped
tree.

The only issue I see is undef/poison in an operand.  Can this break an
optimization, esp. if there is internal reconvergence in the logic tree?

For expressions of more than 2-3 distinct variables you can use technology
mappng to construct an arbitrarily deep tree of LUTs, and then
technology-map to the target architecture. It's likely that the few
applications that would benefit already do some of this optimization
internally.


On Tue, Nov 16, 2021 at 7:55 AM Jay Foad via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > If we're missing 2 variable logic reductions, those are
common/easy
> enough that we should have those in instcombine.
>
> I think I agree with this. There should be 16 canonical forms for the
> bitwise functions on two variables, including degenerate cases like
> "false" as well as the interesting ones like A&~B, ~A^B etc.
It seems
> reasonable that we should be able to simplify AND OR and XOR on any
> pair of canonical forms, and produce another canonical form as the
> result.
>
> For three variables there would be 256 canonical forms, which seems
> far less tractable.
>
> Jay.
>
> On Thu, 11 Nov 2021 at 16:35, Sanjay Patel <spatel at
rotateright.com> wrote:
> >
> > Nice test program! I don't know python well enough to understand
that
> yet, but no reason to be ashamed of hacks. :)
> >
> > If we're missing 2 variable logic reductions, those are
common/easy
> enough that we should have those in instcombine. So yes, it would be great
> if you file bugs for those, and they could be marked with the
'beginner'
> keyword too as a potential easy patch for newcomers to LLVM.
> >
> > There's also a set of recent patch proposals for 3 variable logic
> reductions -- for example, https://reviews.llvm.org/D112276 -- these were
> inspired by a logic lookup table function as discussed in the comments.
> > The extra-use and commuted variations make these harder. IMO, this is
> where there should be a dedicated pass/solver for logic folds if we want
> those optimizations to be complete. Otherwise, there's an explosion of
> possible pattern match combinations.
> >
> >
> > On Thu, Nov 11, 2021 at 6:34 AM Jay Foad <jay.foad at gmail.com>
wrote:
> >>
> >> Hi,
> >>
> >> I tried searching for small bitwise expressions using AND OR XOR
and
> >> NOT that "opt -O3" fails to optimize to a simpler form.
For example:
> >>
> >> (A^B)|~A --> ~(A&B)
> >> https://alive2.llvm.org/ce/z/HpWfzp
> >>
> >> A|B|(A^B) --> A|B
> >> https://alive2.llvm.org/ce/z/UCC6uM
> >>
> >> ((A|B)^C)&A --> A&~C (actually I don't understand
why this one is OK,
> >> even if B might be poison, but alive2 says it is OK)
> >> https://alive2.llvm.org/ce/z/mkvW6p
> >>
> >> I can file bugs for specific examples but I wondered if there was
any
> >> interest in a more systematic approach to finding these missed
> >> optimizations? My approach was to write some very hacky Python
> >> (https://gist.github.com/jayfoad/94f4c68fa3a9aa908db79dbd7e9df80d,
> >> please don't read it) to exhaustively generate programs; then
take all
> >> the programs with a given truth table, run them all through
"opt -O3",
> >> and check that they all got optimized to the same (or at least
equally
> >> short) output.
> >>
> >> Thanks,
> >> Jay.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211116/63aaa8bc/attachment.html>