This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] avoid generating mul intrinsic that lowers as a libcall
AbandonedPublic

Authored by spatel on Aug 8 2022, 4:50 PM.

Details

Summary

This is a minimal fix for issue #56403. We need to avoid creating a libcall to the libcall itself, or we get an infinite loop.

As noted in the bug report, this is not a complete solution. We should be guarding all intrinsic transforms like this with some kind of check to ensure we are not lowering to a libcall, but I don't think that query exists in IR.

I drafted an alternate patch that would move this transform to AggressiveInstCombine and check TTI.isTypeLegal(), but that might go beyond what we want (for example: don't do the transform for i8 types on AArch64?).

Diff Detail

Event Timeline

spatel created this revision.Aug 8 2022, 4:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 8 2022, 4:50 PM
spatel requested review of this revision.Aug 8 2022, 4:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 8 2022, 4:50 PM

Makes sense to me, and should be relatively trivial to merge into 15.x

@andrewrk @nickdesaulniers any thoughts?

spatel added a comment.Aug 9 2022, 5:35 AM

Makes sense to me, and should be relatively trivial to merge into 15.x

Yes, I intentionally made this patch minimal to make merging easy. That does leave out some non-obvious context though - the existing transforms are tested extensively in 6 different files:
fb38b7aab3f23604611 (D65143)
473a063a5e13812878 (D65144)
35fa7b8ad83e6cddb38

This patch doesn't affect any of the motivating types (scalars from i8 to i64 and vectors with those elements).

Also for reference;

/// Legal integers and common types are considered desirable. This is used to
/// avoid creating instructions with types that may not be supported well by the
/// the backend.
/// NOTE: This treats i8, i16 and i32 specially because they are common
///       types in frontend languages.
bool InstCombinerImpl::isDesirableIntType(unsigned BitWidth) const {

I wonder if we should have some more comprehensive solution to the whole "recursive call" thing, as opposed to the ad-hoc transform avoidance we currently use... but this seems fine for now.

llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
4066

The comment here should more specifically call out the possibility of a recursive call. If we have a non-legal divide, we're probably generating a libcall anyway...

spatel updated this revision to Diff 451201.Aug 9 2022, 10:29 AM
spatel marked an inline comment as done.

Patch updated:
Mention the recursive call potential of the transform in the code comment.

spatel abandoned this revision.Sep 12 2022, 9:49 AM

Abandoning - we proceeded with a codegen fix instead (D131521).