Expose LLVM types

[auroranockert]

This might not be a super idea, but It would be really cool and useful in some cases to be able to expose LLVM types like i1, i128, fp128, vectors <16 x i8> etc. to rust, mainly to interface with LLVM intrinsics that take these types as parameters, but also to implement SIMD in Rust.

I don't know how this would be implemented, but it doesn't really matter if it is ugly since only library code would ever need it (probably.)

[bstrie]

I can easily see arguments for including i1, i128, and f128 as first-class types in Rust, but what other types are there (more specifically than "vectors")?

Does this request change in light of the SIMD support that landed in #6214?

[thestinger]

LLVM allows arbitrarily-sized integer types so the only limit is what makes sense to expose, based on hardware support.

[auroranockert]

It does somewhat change in the light of SIMD (and packed structs), since that means that the most pressing types that were missing are now supported. (i128 and f128 are mostly a curiosity imho.)

But at the time the idea was to implement something like

type i1 = llvm_type!(i1);

and then you could get some types that you could otherwise not access (and likely never will be able to access otherwise), like the MIPS DSP ASE type v2q15, or x86mmx.

Ps. Feel free to close nofix, if it is a bad idea.

[pnkfelix]

As I understand the proposal, using these types would require either

• adding a collection of intrinsics to operate on these types, or,
• changes to the code generator to support them?

Nominating for "far future" milestone. (That, or close as "nofix"; I don't have a preference.)

[auroranockert]

There are already intrinsics operating on the weird SIMD and accumulator types, we just cannot call them since we don't support the types.

(Unlike iN and f128 etc., which would need actual code generator support, but yes, "far future" is the only milestone that makes sense)

[graydon]

As-proposed, I think most of the moz folks are against this (discussing in triage meeting); SIMD of course needs support and it's reasonable to assume f128 and i128 will show up as new suffixes/literals and types in the prelude at some point. Otherwise I think not: it's too much tying the language to LLVM.

Closing WONTFIX.