You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today we scatter/gather all extract values of struct return types. Thats out of lock step with how we split the call. The fix is to check if the call was trivially vectorizable before. handling the extract element case.
Background
This is rather assert while we are doing Scatterer::operator[] and we are creating CreateExtractElement but Type is not a Vector but a Structure. Adding uadd.with.overflow to isTriviallyScalarizable is 'fixing' this.
Thats a bug. Adding to isTriviallyScalarizable is not the right fix. Whats going on is because uadd.with.overflow isn't in isTriviallyScalarizable we aren't splitting the calls so when we call Scatterer Op0 it isn't operating on the right type. A correct fix wouldn't replace extract element unless we scalarized the call.
Test case:
define <3 x i32> @test_(<3 x i32> %a, <3 x i32> %b) {
%r = call { <3 x i32>, <3 x i1> } @llvm.uadd.with.overflow.v3i32(<3 x i32> %b, <3 x i32> %b)
%el = extractvalue { <3 x i32>, <3 x i1> } %r, 0
ret <3 x i32> %el
}
…able
Since uadd_with_overflow is now marked isTriviallyScalarizable, another intrinsic needs to take its place for testing the bug fix introduced in llvm#113625 for issue llvm#113624.
Issue
Today we scatter/gather all extract values of struct return types. Thats out of lock step with how we split the call. The fix is to check if the call was trivially vectorizable before. handling the extract element case.
Background
Test case:
Originally posted by @farzonl in #111569 (comment)
The text was updated successfully, but these errors were encountered: