[PATCH] D68408: [InstCombine] Negator - sink sinkable negations
Sanjay Patel via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Apr 14 14:05:23 PDT 2020
spatel added a comment.
In D68408#1978925 <https://reviews.llvm.org/D68408#1978925>, @nikic wrote:
> In D68408#1977656 <https://reviews.llvm.org/D68408#1977656>, @spatel wrote:
>
> > Yes, there's no clear line that I know of. It's like IR canonicalization - we make the rules up as we go along and adapt the surrounding logic to work with the current format. I think we've overcome the limitation for this patch, so we don't need to gate this patch on a decision, but I think we still have the problem. The clearest sign is that -- within instcombine -- we have bailouts for otherwise accepted canonicalizations only if we "matchSelectPattern()".
>
>
> FWIW I agree that we need to reevaluate this decision and at least introduce min/max intrinsics. These are special-cased in too many places for the current treatment as a simple compare and select to still make sense. Especially when we take into account that there seems to be a new min/max related infinite loop every other month, and that the icmp/select representation has ill-defined behavior when it comes to undef. I expect the effort for introducing these intrinsics will be pretty similar to saturating add/sub, and would be happy to chip in...
Sounds like general agreement for the people on this review (and sorry for going off-topic for this specific patch). I'll post something to llvm-dev after trying to dig up the earlier discussions for those intrinsics.
And looks like we have this month's infinite loop here :) -
https://bugs.llvm.org/show_bug.cgi?id=45539
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68408/new/
https://reviews.llvm.org/D68408
More information about the llvm-commits
mailing list