VCVTNEEBF162PS

VCVTNEEBF162PS reads 128 or 256 bits of bfloat16 values from memory and widens the even-numbered ones, elements 0, 2, 4 and so on, to singles: each doubleword of the destination gets the low word of the matching doubleword in memory. Four results fill an XMM register and eight a YMM one; the bits above are cleared, as in any VEX instruction. VCVTNEOBF162PS takes the odd elements, and the two together widen a vector of pairs, the layout in which VDPBF16PS takes them; VCVTNEPS2BF16 is the narrowing the other way.

A move of bits#

A bfloat16 value is the upper half of a single, so the conversion cannot round or overflow: Intel’s pseudocode puts the 16 bits in bits 31:16 and zeros below. Nothing is interpreted on the way. A denormal stays a denormal, whatever MXCSR.DAZ says; a signaling NaN stays signaling. No exception is reported, and MXCSR is neither read nor written, which is the “NE” of the name. For the even elements the result is the doubleword shifted left by 16, as VPSLLD by 16 would give it from a register.

Memory only#

The source must be in memory: ModRM with a register operand is not an encoding. Intel’s optimization manual explains why for Crestmont, the E-core of Sierra Forest: it widens bfloat16 and FP16 in the load pipelines, so the conversion takes no floating-point execution resources. There is no alignment requirement. The encoding is VEX.F3.0F38.W0 B0; with F2 the same opcode is the odd form, and with 66 and no prefix the FP16 forms.

AVX-NE-CONVERT (CPUID leaf 7, subleaf 1, EDX bit 5) is on Sierra Forest, Grand Ridge, Arrow Lake H and Diamond Rapids, Intel’s list says; Zen 5 lacks it. GCC 14 and Clang 23 compile _mm256_cvtneebf16_ps(p) with -mavxneconvert to vcvtneebf162ps ymm0, ymmword ptr [rdi], but neither uses it for C code converting __bf16 to float in our builds: Clang 23 shifts with VPMOVZXWD and VPSLLD, and GCC 14 calls __extendbfsf2 for each element, at -march=sierraforest too.

In the optimization guide

What the optimization guide says about VCVTNEEBF162PS, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Crestmont and Gracemont

• Vectors and AVX2: Crestmont widens BF16 and FP16 to single precision in the load pipelines, using no vector port.

Forms

Latency and throughput

Data flow

Where the elements of the sources go, element 0 on the right; results that depend on a control value are drawn for an example. How to read.

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

for i in range(VL // 32):
    ymm1.f32[i] = to_f32_ne(mem.bf16[2 * i])
# ymm1 is zeroed from bit VL up

Operands

Flags

None: XED records no flag that the forms test or change.

Exceptions

The exception class is XED's name for the set of exception conditions that a form follows. How to read.

All forms

avx-type-4

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to VCVTNEEBF162PS, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More AVX-NE-CONVERT instructions

• VBCSTNEBF162PS
• VBCSTNESH2PS
• VCVTNEEPH2PS
• VCVTNEOBF162PS
• VCVTNEOPH2PS
• VCVTNEPS2BF16