<div dir="ltr">For any number of inputs, you can build a look-up table (LUT).<div><br></div><div>Some processor architectures have LUT instructions.  For those, your built LUT can be used directly.<br><br>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 16, 2021 at 7:55 AM Jay Foad via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> If we're missing 2 variable logic reductions, those are common/easy enough that we should have those in instcombine.<br>
<br>
I think I agree with this. There should be 16 canonical forms for the<br>
bitwise functions on two variables, including degenerate cases like<br>
"false" as well as the interesting ones like A&~B, ~A^B etc. It seems<br>
reasonable that we should be able to simplify AND OR and XOR on any<br>
pair of canonical forms, and produce another canonical form as the<br>
result.<br>
<br>
For three variables there would be 256 canonical forms, which seems<br>
far less tractable.<br>
<br>
Jay.<br>
<br>
On Thu, 11 Nov 2021 at 16:35, Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>> wrote:<br>
><br>
> Nice test program! I don't know python well enough to understand that yet, but no reason to be ashamed of hacks. :)<br>
><br>
> 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.<br>
><br>
> There's also a set of recent patch proposals for 3 variable logic reductions -- for example, <a href="https://reviews.llvm.org/D112276" rel="noreferrer" target="_blank">https://reviews.llvm.org/D112276</a> -- these were inspired by a logic lookup table function as discussed in the comments.<br>
> 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.<br>
><br>
><br>
> On Thu, Nov 11, 2021 at 6:34 AM Jay Foad <<a href="mailto:jay.foad@gmail.com" target="_blank">jay.foad@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I tried searching for small bitwise expressions using AND OR XOR and<br>
>> NOT that "opt -O3" fails to optimize to a simpler form. For example:<br>
>><br>
>> (A^B)|~A --> ~(A&B)<br>
>> <a href="https://alive2.llvm.org/ce/z/HpWfzp" rel="noreferrer" target="_blank">https://alive2.llvm.org/ce/z/HpWfzp</a><br>
>><br>
>> A|B|(A^B) --> A|B<br>
>> <a href="https://alive2.llvm.org/ce/z/UCC6uM" rel="noreferrer" target="_blank">https://alive2.llvm.org/ce/z/UCC6uM</a><br>
>><br>
>> ((A|B)^C)&A --> A&~C (actually I don't understand why this one is OK,<br>
>> even if B might be poison, but alive2 says it is OK)<br>
>> <a href="https://alive2.llvm.org/ce/z/mkvW6p" rel="noreferrer" target="_blank">https://alive2.llvm.org/ce/z/mkvW6p</a><br>
>><br>
>> I can file bugs for specific examples but I wondered if there was any<br>
>> interest in a more systematic approach to finding these missed<br>
>> optimizations? My approach was to write some very hacky Python<br>
>> (<a href="https://gist.github.com/jayfoad/94f4c68fa3a9aa908db79dbd7e9df80d" rel="noreferrer" target="_blank">https://gist.github.com/jayfoad/94f4c68fa3a9aa908db79dbd7e9df80d</a>,<br>
>> please don't read it) to exhaustively generate programs; then take all<br>
>> the programs with a given truth table, run them all through "opt -O3",<br>
>> and check that they all got optimized to the same (or at least equally<br>
>> short) output.<br>
>><br>
>> Thanks,<br>
>> Jay.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>