SystemZ Z13 Unsupported vector argument or return type

[Quuxplusone]

Bugzilla Link	PR42075
Status	NEW
Importance	P enhancement
Reported by	Andrew Wock (ajwock@gmail.com)
Reported on	2019-05-30 13:51:22 -0700
Last modified on	2019-07-18 06:12:31 -0700
Version	trunk
Hardware	PC FreeBSD
CC	Kevin.Neal@sas.com, llvm-bugs@lists.llvm.org, uweigand@de.ibm.com
Fixed by commit(s)
Attachments	e_fdiv_v3f64.ll (16397 bytes, text/plain)
Blocks
Blocked by
See also

Created attachment 22053
A file that, when run, should exemplify the bug.

For some reason, when llc is run with options -mtriple=s390x -mcpu=z13 (without
the second argument, the issue does not occur), llc prints "LLVM ERROR:
Unsupported vector argument or return type" if the input file contains any
function whose arguments or return types are, particularly v3f64, but also
generally any vector type that is considered to be an extended type, such as
v6f32.

It fails at an assert at VerifyVectorType in
lib/Target/SystemZ/SystemZISelLowering.cpp.  As far as I can tell, the code
seems to run to completion and produce correct assembly as long as this assert
is simply skipped in those cases.  However, there is a comment indicating that
a single element vector containing a 128 bit type is not supporting, suggesting
that the assert was meant to catch this case but also ends up catching many
other cases that it is not supposed to.

I have attached a test file.

[Quuxplusone]

Attached e_fdiv_v3f64.ll (16397 bytes, text/plain): A file that, when run, should exemplify the bug.

[Quuxplusone]

Right now, the SystemZ backend really only supports those LLVM vector types as argument / return types that the clang frontend will ever create.

(Specifically, clang will never use <3 x double> as LLVM argument / return type, but will create an indirect argument instead.)

This is mostly a sanity check given that we've not actually formally defined an ABI for those other types at this point, and I'd rather have a compile error than have the compiler just implicitly create a defacto ABI.

In principle, we could support those other types as well, by explicitly defining an ABI and ensuring this is correctly implemented in the back-end.

I'll have a look.