[llvm-dev] Missed optimization of bitwise expressions

David Jones via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 16 05:07:39 PST 2021


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>


More information about the llvm-dev mailing list