Why does Roslyn emit conv.r8 after conv.r.un instruction for casting to float?

[eterekhin]

Hi all!
Take a look at this, please (you can play with it here)

I can't figure out why Roslyn emits conv.r8 instruction if conv.r.un already means cast to double, right? Unfortunately, I can't find enough info about this instruction in the spec (would be great if anyone could point out me to where I should look). I found this description - "Convert unsigned integer to floating-point, pushing F on stack." According to this description, emitting conv.r8 looks redundant.

[huoyaoyuan]

It looks like that conv.r.un behaves like a prefix, not a full instruction. It specifies the source to be unsigned integer, but doesn't specify the destination size. Only r8 means double.

[eterekhin]

Yes, that makes sense, thanks. I just thought that 'conv.r8' is a redundant instruction for casting to double because jit can convert an unsigned number to a double if 'conv.r.un' is met.

But in fact, in the case where we cast an unsigned number to float, it would be silly if jit would first convert the number to double(when it met conv.r.un instruction), and then cast it to float. Emitting this instruction allows jit to understand that it deals with an unsigned number, and jit can read the next instruction to get information about the type to which we want to cast.

[PathogenDavid]

The short answer is that CLI does not support storing unsigned integers on the evaluation stack so you have to clarify whether a given integer is signed or not using specific instructions. conv.r8 alone would convert i as if it were signed.

---

(Note: Page number and section references are based on the Microsoft-specific variant of ECMA-335. I don't have a super good reason for using it specifically, but I thought I should point it out. This version isn't officially published anymore as far as I'm aware, but you can find it via The Wayback Machine.)

Partition I §12.3.2.1 The Evaluation Stack (pg 88) describes the evaluation stack, and specifically it lists what can be represented on the stack:

While the CLI, in general, supports the full set of types described in §12.1, the CLI treats the evaluation stack
in a special way. While some JIT compilers might track the types on the stack in more detail, the CLI only
requires that values be one of:

• int64, an 8-byte signed integer
• int32, a 4-byte signed integer
• native int, a signed integer of either 4 or 8 bytes, whichever is more convenient for the target architecture
• F, a floating point value (float32, float64, or other representation supported by the underlying hardware)
• &, a managed pointer
• O, an object reference
• *, a “transient pointer,” which can be used only within the body of a single method, that points to a value known to be in unmanaged memory (see the CIL Instruction Set specification for more details. * types are generated internally within the CLI; they are not created by the user).
• A user-defined value type

It's a pretty short list. Two things to note here:

The first thing to note is the lack of unsigned types. The standard clarifies this after this list:

The other types are synthesized through a combination of techniques:
[...]

• Special instructions treat an integer on the stack as though it were unsigned.

The other thing to notice is this F type. This F type is defined earlier in the standard in Partition I §12.1.3 Handling of floating-point data types (pg 79):

Storage locations for floating-point numbers (statics, array elements, and fields of classes) are of fixed size. The supported storage sizes are float32 and float64. Everywhere else (on the evaluation stack, as arguments, as return types, and as local variables) floating-point numbers are represented using an internal floating-point type.

Basically F represents the abstract idea of a float without a specific size. You can think of it as a platform-defined floating point value with no size.

---

So with that knowledge, let's look at the way those instructions are defined. Both are defined in Partiion III §3.27 conv.<to type> - data conversion (pg 62).

Both have a stack transition of ..., value -> ..., result. Which basically just means they pop the value off the top of the stack, and push the converted value back onto the stack. (No surprises there.)

• conv.r8 is defined as "Convert to float64, pushing **F`** on stack."
• conv.r.un is defined as "Convert unsigned integer to floating-point, pushing F on stack."

The final thing to know is how "convert" is defined in this context. The behavior of converting between values of different types is defined in Partition III §1.5 Table 8: Conversion Operations. A particular thing to note is the conversion between F and all float types, which is defined as changing precision.

So with all of that, your IL can be read as:

Instruction	Stack Before	Stack After	Meaning (in this context)
ldarg.1	…	…, int32	Load argument 1 (i) onto the stack
conv.r.un	…, int32	…, F	Interpreting it as unsigned, convert the value on the top of the stack to F
conv.r8	…, F	…, F	Change the precision of the F to be float64.

If you want to think of it this way: conv.r.un converts the unsigned integer to a system-specific floating point value and conv.r8 clarifies that it should be represented as an 8 byte floating point value.