"Part type doesn't match vector breakdown!" assertion when mixing SIMD and MIPS

[alexcrichton]

Bugzilla Link	33883
Resolution	FIXED
Resolved on	Aug 01, 2017 16:45
Version	5.0
OS	All
Blocks	#33196
CC	@zmodem

Extended Description

In trying to upgrade rust-lang/rust to LLVM 5.0 we've discovered that one of our tests is failing, namely this IR:

; ModuleID = 'simd.cgu-0.rs'
source_filename = "simd.cgu-0.rs"
target datalayout = "E-m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32-S64"
target triple = "mips-unknown-linux-gnu"

; simd::foo
; Function Attrs: uwtable
define <4 x float> @​_ZN4simd3foo17hebb969c5fb39a194E(<4 x float>) unnamed_addr #​0 {
start:
%1 = call <4 x float> @​llvm.sqrt.v4f32(<4 x float> %0)
br label %bb1

bb1: ; preds = %start
ret <4 x float> %1
}

; simd::bar
; Function Attrs: uwtable
define <4 x i32> @​_ZN4simd3bar17hdc8ee07458cf8c7bE(<4 x i32>, <4 x i32>) unnamed_addr #​0 {
start:
%2 = call <4 x i32> @​integer(<4 x i32> %0, <4 x i32> %1)
br label %bb1

bb1: ; preds = %start
ret <4 x i32> %2
}

; Function Attrs: nounwind readnone speculatable
declare <4 x float> @​llvm.sqrt.v4f32(<4 x float>) unnamed_addr #​1

; Function Attrs: nounwind
declare <4 x i32> @​integer(<4 x i32>, <4 x i32>) unnamed_addr #​2

attributes #​0 = { uwtable }
attributes #​1 = { nounwind readnone speculatable }
attributes #​2 = { nounwind }

when compiled with llc -filetype=obj -mtriple=mips-unknown-linux-gnu foo.ll will fail with

llc: /home/alex/code/rust3/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:616: void getCopyToPartsVector(llvm::SelectionDAG&, const llvm::SDLoc&, llvm::SDValue, llvm::SDValue*, unsigned int, llvm::MVT, const llvm::Value*, bool): Assertion `RegisterVT == PartVT && "Part type doesn't match vector breakdown!"' failed.

and this stack trace: https://gist.github.com/alexcrichton/4697cc30fdb94c56a480e1d2c2952479

[llvmbot]

Investigating. MIPS added support for vector types to be part of the calling convention relatively recently. Does rust-lang always lower SIMD types to types for MIPS?

[alexcrichton]

Does rust-lang always lower SIMD types to types for MIPS?

AFAIK yes, but if this is considered a frontend bug that's also ok! We can try to work around it on our end.

[llvmbot]

Does rust-lang always lower SIMD types to types for MIPS?

AFAIK yes, but if this is considered a frontend bug that's also ok! We can
try to work around it on our end.

Yes, technically this is a front-end bug for rust-lang as vector types until recently could not be passed directly as arguments or returns for MIPS for LLVM-IR.

Currently, clang lowers the passing of vector arguments by decomposing the vector into scalar types and passing them as arguments (for MIPS).

However an internal request required my effort to develop support for vector types directly in the calling convention (CC) for LLVM IR--normally clang alters the types such that our CC handles them properly. I'm in favour of getting the MIPS backend to support vector types directly in accordance with our ABIs.

I have a rough idea of a solution for this ticket.

[llvmbot]

https://reviews.llvm.org/D35765 for the patch.

[alexcrichton]

Simon if you're curious (and it looks like you know MIPS!) would you be able to help us with llvm/llvm-bugzilla-archive#33978 as well?

[llvmbot]

Simon if you're curious (and it looks like you know MIPS!) would you be able
to help us with llvm/llvm-bugzilla-archive#33978 as well?

Will do. Feel free to CC on anything issues related to MIPS in LLVM, I'll (should) be able resolve them or find the right person internally to deal with them.

[alexcrichton]

Awesome, thanks!

[llvmbot]

r309561.

[zmodem]

r309561.

Simon: Should this be merged to 5.0?

Alex: When filing issues about upgrading to 5.0, please feel free to mark them as blockers of bug 33849 so we can get the fixes into the release.

[llvmbot]

r309561.

Simon: Should this be merged to 5.0?

Yes, I've had another similar report, llvm/llvm-bugzilla-archive#34006 . I was going to request that revision be merged for 5.0, was giving it a little time to see if any more reports came in.

Thanks.

[alexcrichton]

r309561.

Simon: Should this be merged to 5.0?

Alex: When filing issues about upgrading to 5.0, please feel free to mark
them as blockers of bug 33849 so we can get the fixes into the release.

Oh certainly will do! Sorry didn't realize I could do that, but I'll be sure to do so in the future

[zmodem]

r309561.

Simon: Should this be merged to 5.0?

Yes, I've had another similar report, llvm/llvm-bugzilla-archive#34006 . I was going to request that
revision be merged for 5.0, was giving it a little time to see if any more
reports came in.

I've merged this one as r309767 in the meantime.