<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 10:44 AM Roman Lebedev 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">Hello all.<br>
<br>
This is a proposal to introduce 5 new integer intrinsics:<br>
* absolute value<br>
* signed min<br>
* signed max<br>
* unsigned min<br>
* unsigned max<br>
<br>
This is motivated by the fact that we keep working around<br>
not having these intrinsics, and that constantly leads us into<br>
having more workarounds, and causes infinite combine loops.<br>
<br>
Here's a (likely incomplete!) list of motivational bugs:<br>
<br>
infinite loops:<br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=46271" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=46271</a> / <a href="https://reviews.llvm.org/D81698" rel="noreferrer" target="_blank">https://reviews.llvm.org/D81698</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=45539" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=45539</a> /<br>
<a href="https://reviews.llvm.org/rG01bcc3e93714" rel="noreferrer" target="_blank">https://reviews.llvm.org/rG01bcc3e93714</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=44835" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=44835</a> / <a href="https://reviews.llvm.org/D74278" rel="noreferrer" target="_blank">https://reviews.llvm.org/D74278</a><br>
<a href="https://reviews.llvm.org/D68408#1976760" rel="noreferrer" target="_blank">https://reviews.llvm.org/D68408#1976760</a><br>
<a href="https://reviews.llvm.org/D59378" rel="noreferrer" target="_blank">https://reviews.llvm.org/D59378</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=38915" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=38915</a> / <a href="https://reviews.llvm.org/D51964" rel="noreferrer" target="_blank">https://reviews.llvm.org/D51964</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=37526" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=37526</a> / <a href="https://reviews.llvm.org/rL332855" rel="noreferrer" target="_blank">https://reviews.llvm.org/rL332855</a><br>
<br>
misc:<br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=44025" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=44025</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=43310" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=43310</a> / <a href="https://reviews.llvm.org/rL372510" rel="noreferrer" target="_blank">https://reviews.llvm.org/rL372510</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=35607" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=35607</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=35642" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=35642</a> / <a href="https://reviews.llvm.org/D41136" rel="noreferrer" target="_blank">https://reviews.llvm.org/D41136</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=41083" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=41083</a> / <a href="https://reviews.llvm.org/D74285" rel="noreferrer" target="_blank">https://reviews.llvm.org/D74285</a><br>
<a href="https://reviews.llvm.org/D70148" rel="noreferrer" target="_blank">https://reviews.llvm.org/D70148</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=31751" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=31751</a> /<br>
<a href="https://reviews.llvm.org/D26096" rel="noreferrer" target="_blank">https://reviews.llvm.org/D26096</a> / <a href="https://reviews.llvm.org/rL293345" rel="noreferrer" target="_blank">https://reviews.llvm.org/rL293345</a><br>
<br>
I believe we can do better than that if we stop just treating some IR patterns<br>
as being canonical and desperately trying not to break/loose track of them,<br>
but instead do a sensible thing and actually make them first class citizens,<br>
by introducing intrinsics and use then throughout.<br>
<br>
This has been previously discussed in:<br>
<a href="https://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html</a><br>
<br>
Proposed LangRef semantics: <a href="https://reviews.llvm.org/D81829" rel="noreferrer" target="_blank">https://reviews.llvm.org/D81829</a><br>
Proposed alive2 implementation: <a href="https://github.com/AliveToolkit/alive2/pull/353" rel="noreferrer" target="_blank">https://github.com/AliveToolkit/alive2/pull/353</a><br></blockquote><div><br></div><div>I'm also strongly in favor of this proposal.</div><div><br></div><div>Next to the issues already mentioned, this also fixes issues related to undef handling. For example, umax(%x, C) is not actually guaranteed to be >= C. That's because the current umax representation has two uses of %x, which may take on independent values if %x is undef. This makes a number of "common sense" folds invalid. Having dedicated min/max intrinsics avoids that problem.</div><div><br></div><div>Regards,<br></div><div>Nikita<br></div></div></div>