[llvm-dev] Strange types on x86 vcvtph2ps and vcvtps2ph intrinsics

[Dan Liew via llvm-dev]

Hi,

>> Here's what seems weird to me:
>>
>> * For the 4 wide intrinsics (``_128`` suffix) some of the types are
>> wider than they need to be. For example ``int_x86_vcvtph2ps_128``
>> takes <8 x i16> as an argument but this intrinsic only uses the first
>> four lanes so why is the argument type not <4 x i16>?
>> ``int_x86_vcvtps2ph_128`` also has the same oddity but on its return
>> type (returns <8 x i16> but only the first four are relevant).
>
> One reason is that <4 x i16> is too small to be a legal SSE vector
> type, so the IR intrinsics, much like the Intel C intrinsics and the
> instructions, are defined in terms of the widened <8 x i16> (with
> either __m128, or xmm registers).

Ah I see. Makes sense.

>> * The use of ``i16`` types also seems a little strange given that the
>> more semantically correct ``f16`` type and vectorized forms (e.g.
>> ``llvm_v4f16_ty``) are available. Sure I can use a bitcast with the
>> intrinsics to get the type I want in the IR but why were ``i16`` was
>> chosen over using ``f16``?
>
> f16 wasn't, until recently, very well supported. It still has rough
> edges on targets without native scalar register classes such as X86.

What do you mean by "register classes"? Sorry if this is a dumb question.

> Instead, these targets use i16, and do the conversion with other
> (native) FP types using the dedicated convert.to/from.fp16 intrinsics.
> We match that here and use an i16 element type.

I remember seeing that intrinsic in the language reference but
unfortunately ``convert.to.fp16`` [1] isn't useful
for what I'm working on because it doesn't specify a rounding mode.
fp16 has so little precision that the rounding mode
**really matters**.

> Someday, we'll get rid of these intrinsics and use half everywhere,
> but we're not there yet!

Okay.

> HTH,

Very helpful, thanks.


[1] http://llvm.org/docs/LangRef.html#llvm-convert-to-fp16-intrinsic

Thanks,
Dan.