[llvm-dev] [RFC] Integer Intrinsics for abs, in unsigned/signed min/max

[Chris Lattner via llvm-dev]

Cool, thanks for driving this Roman.  I’d recommend splitting up the langref patch and landing each intrinsic along with its implementation.  We’ll need verifier support, ISel legalization support (for targets that don’t implement it) etc.  Adoption by targets doesn’t seem like a requirement of the first patch.

-Chris

> On Jun 18, 2020, at 1:26 PM, Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> As per popular demand i've dropped misleading "reduction"
> wording/naming from them, updated https://reviews.llvm.org/D81829
> 
> So far all the responses are favorable to this proposal.
> 
> Roman.
> 
> On Mon, Jun 15, 2020 at 11:58 PM Nikita Popov <nikita.ppv at gmail.com> wrote:
>> 
>> On Mon, Jun 15, 2020 at 10:44 AM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> Hello all.
>>> 
>>> This is a proposal to introduce 5 new integer intrinsics:
>>> * absolute value
>>> * signed min
>>> * signed max
>>> * unsigned min
>>> * unsigned max
>>> 
>>> This is motivated by the fact that we keep working around
>>> not having these intrinsics, and that constantly leads us into
>>> having more workarounds, and causes infinite combine loops.
>>> 
>>> Here's a (likely incomplete!) list of motivational bugs:
>>> 
>>> infinite loops:
>>> https://bugs.llvm.org/show_bug.cgi?id=46271 / https://reviews.llvm.org/D81698
>>> https://bugs.llvm.org/show_bug.cgi?id=45539 /
>>> https://reviews.llvm.org/rG01bcc3e93714
>>> https://bugs.llvm.org/show_bug.cgi?id=44835 / https://reviews.llvm.org/D74278
>>> https://reviews.llvm.org/D68408#1976760
>>> https://reviews.llvm.org/D59378
>>> https://bugs.llvm.org/show_bug.cgi?id=38915 / https://reviews.llvm.org/D51964
>>> https://bugs.llvm.org/show_bug.cgi?id=37526 / https://reviews.llvm.org/rL332855
>>> 
>>> misc:
>>> https://bugs.llvm.org/show_bug.cgi?id=44025
>>> https://bugs.llvm.org/show_bug.cgi?id=43310 / https://reviews.llvm.org/rL372510
>>> https://bugs.llvm.org/show_bug.cgi?id=35607
>>> https://bugs.llvm.org/show_bug.cgi?id=35642 / https://reviews.llvm.org/D41136
>>> https://bugs.llvm.org/show_bug.cgi?id=41083 / https://reviews.llvm.org/D74285
>>> https://reviews.llvm.org/D70148
>>> https://bugs.llvm.org/show_bug.cgi?id=31751 /
>>> https://reviews.llvm.org/D26096 / https://reviews.llvm.org/rL293345
>>> 
>>> I believe we can do better than that if we stop just treating some IR patterns
>>> as being canonical and desperately trying not to break/loose track of them,
>>> but instead do a sensible thing and actually make them first class citizens,
>>> by introducing intrinsics and use then throughout.
>>> 
>>> This has been previously discussed in:
>>> https://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html
>>> 
>>> Proposed LangRef semantics: https://reviews.llvm.org/D81829
>>> Proposed alive2 implementation: https://github.com/AliveToolkit/alive2/pull/353
>> 
>> 
>> I'm also strongly in favor of this proposal.
>> 
>> 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.
>> 
>> Regards,
>> Nikita
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev