This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] correct operands of shouldChangeType() for casted phi transform
ClosedPublic

Authored by spatel on Feb 3 2020, 10:12 AM.

Details

Summary

This is a bug noted in the recent D72733 and seen in the similar transform just above the changed source code.

I added tests with illegal types and zexts to show the bug - we could transform legal phi ops to illegal, etc. I did not add tests with trunc because we won't see any diffs on those patterns. That is because InstCombiner::SliceUpIllegalIntegerPHI() appears to do those transforms independently of datalayout. It can also create more casts than are present in existing code. I'm not sure if that is intended or not, but that might be another patch.

There are some existing regression tests that do not include a datalayout that would be altered by this fix. I assumed that the lack of a datalayout in those regression files is an oversight, so I added the minimal layout (make i32 legal) necessary to preserve behavior on those tests.

Diff Detail

Event Timeline

spatel created this revision.Feb 3 2020, 10:12 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 3 2020, 10:12 AM
lebedev.ri accepted this revision.Feb 3 2020, 10:27 AM

Looks good.

This revision is now accepted and ready to land.Feb 3 2020, 10:27 AM
This revision was automatically updated to reflect the committed changes.

This causes failed asserts for me. With https://martin.st/temp/substtml-preproc.c, built with clang -target i686-w64-mingw32 -c -O2 substtml-preproc.c, I'm getting this:

clang: ../include/llvm/Support/Alignment.h:384: llvm::Align llvm::operator/(llvm::Align, uint64_t): Assertion `Lhs != 1 && "Can't halve byte alignment"' failed.

CC'ing Align suspects

This causes failed asserts for me. With https://martin.st/temp/substtml-preproc.c, built with clang -target i686-w64-mingw32 -c -O2 substtml-preproc.c, I'm getting this:

clang: ../include/llvm/Support/Alignment.h:384: llvm::Align llvm::operator/(llvm::Align, uint64_t): Assertion `Lhs != 1 && "Can't halve byte alignment"' failed.
spatel added a comment.Feb 9 2020, 8:53 AM

CC'ing Align suspects

This causes failed asserts for me. With https://martin.st/temp/substtml-preproc.c, built with clang -target i686-w64-mingw32 -c -O2 substtml-preproc.c, I'm getting this:

clang: ../include/llvm/Support/Alignment.h:384: llvm::Align llvm::operator/(llvm::Align, uint64_t): Assertion `Lhs != 1 && "Can't halve byte alignment"' failed.

I'm not seeing a bug in this patch itself. Here's a reduced test that crashes with that assert with only "opt -codegenprepare":

target datalayout = "e-m:x-p:32:32-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:32-n8:16:32-a:0:32-S32"
target triple = "i686-w64-windows-gnu"

define void @ttml_read_coords(float %x, i64* %p) {
  %b = bitcast float %x to i32
  %z = zext i32 0 to i64
  %s = shl nuw nsw i64 %z, 32
  %z2 = zext i32 %b to i64
  %o = or i64 %s, %z2
  store i64 %o, i64* %p, align 1
  ret void
}

I'll try to fix this tomorrow if nobody else gets to it sooner.

"opt -codegenprepare":

I think you meant llc. Thanks for the repro. D73274 is indeed responsible for the crash, but it only exhibited an issue with the existing code: An alignment of 1 was previously silently changed to an alignment of 0. The new typed Align catches this: When splitting a 1-aligned store into two stores, both stores are 1-aligned, instead of one being 1-aligned and the other being 0-aligned (which does not really mean anything since it has different semantics depending on where you are in LLVM)

I'll send a fix.

"opt -codegenprepare":

I think you meant llc.

With CGP, we can use either llc or opt to test, but if the bug is visible/reproducible with opt, then it's better to use that invocation. That's because the regression test can then be an IR --> IR test, and that is (almost?) always simpler to test/understand than IR --> some-other-language.

I'll send a fix.

Thanks! For reference, I think this is same/similar to PR44851 (the test case there is slightly smaller):
https://bugs.llvm.org/show_bug.cgi?id=44851