The "no." opcode prefix is not implemented

[ltrzesniewski]

ECMA-335 specifies the no. opcode prefix as the following (III.2.2):

This prefix indicates that the subsequent instruction need not perform the specified fault check
when it is executed. The byte that follows the instruction code indicates which checks can
optionally be skipped.

In short, it allows for automatic type checks, range checks or null checks to be skipped, which would be useful for optimizing hot code paths.

The current implementation throws InvalidProgramException whenever it encounters this prefix. This opcode is simply marked as unused right now:

https://github.com/dotnet/coreclr/blob/8499136a9a79fd37a4acb9dc690a4815edd8081d/src/inc/opcode.def#L320

Here's a simple method which reproduces the problem:

.method private hidebysig static 
	int32 NoPrefix () cil managed 
{
	.maxstack 2

	IL_0000: ldc.i4.1
	IL_0001: newarr [mscorlib]System.Int32
	IL_0006: ldc.i4.0
	IL_0007: no. 6 // this is rangecheck | nullcheck
	IL_000a: ldelem.i4
	IL_000b: ret
}

category:correctness
theme:msil
skill-level:intermediate
cost:medium

[tannergooding]

I would think that, at the very least, we should ignore the opcode (other than the "correctness/verifiability" checks) rather than throwing InvalidProgramException.

I do think that supporting the opcode would be beneficial though, as it is basically a built-in way of doing certain JIT hints (https://github.com/dotnet/corefx/issues/26188).

[tannergooding]

NOTE: Ignoring the prefix is allowed by the spec:

This prefix indicates that the subsequent instruction need not perform the specified fault check
when it is executed. The byte that follows the instruction code indicates which checks can
optionally be skipped. This instruction is not verifiable.

0x01: typecheck (castclass, unbox, ldelema, stelem, stelem). The CLI can optionally skip
any type checks normally performed as part of the execution of the subsequent instruction.
InvalidCastException can optionally still be thrown if the check would fail.

0x02: rangecheck (ldelem., ldelema, stelem.). The CLI can optionally skip any array range
checks normally performed as part of the execution of the subsequent instruction.
IndexOutOfRangeException can optionally still be thrown if the check would fail.

0x04: nullcheck (ldfld, stfld, callvirt, ldvirtftn, ldelem., stelem., ldelema). The CLI can
optionally skip any null-reference checks normally performed as part of the execution of the
subsequent instruction. NullReferenceException can optionally still be thrown if the check
would fail.

[sharwell]

I would think that, at the very least, we should ignore the opcode (other than the "correctness/verifiability" checks) rather than throwing InvalidProgramException.

This would also be a completely valid implementation of the instructions. Unlike the tail. prefix, the no. prefix specifies optional behavior.

[ltrzesniewski]

Yes, it's optional, and ignoring it would be the very least in order to satisfy the spec.

But I'd like to see it fully supported. I'm not familiar with the JIT implementation so I'm speculating here, but I'd guess that optionally removing existing checks shouldn't be too hard to implement.

[john-h-k]

If there is still use in this, I am currently implementing this so that the JIT just ignores it - during import, it just validates that the flags are correct and the opcode is correct and then does nothing with it. However, there are a couple of questions around it i am not sure about:

• Should no. 0x00 be invalid, or the same as not having it? (currently illegal to not have it
• Should we just read the bits of interest (0x1, 0x2, 0x4), or should we ensure no other bits are set?
• Should there be a PREFIX_NO added to prefixFlags that is set, but just currently ignored, or should it not do that and have no side effects other than necessary (codeAddr++ etc)?

[ltrzesniewski]

TBH implementing it so it's ignored is wasted effort unless it's a first step towards real support.

[john-h-k]

Implementing it so it is ignored would mean there was the potential for langs to expose it, even if it initially does nothing, which could make it worth it to actually make it omit the checks

[john-h-k]

Also, to be picky, helps ECMA compliance

[ltrzesniewski]

If future compatibility is what you want, I'd just ignore all invalid uses. This could be helpful if another flag is added to the instruction in the future. But that's only my opinion 😉

[john-h-k]

Currently have set it to only read bits it should be concerned with, so yeah, invalid and zero values are allowed. Am currently attempting to implement removal of range checks through GTF_INX_RNGHCK, so that will give it some actual meaning.

[john-h-k]

However, small issue so far :|
no. prefix is basically 3 seperate prefixes - typecheck, rangecheck, nullcheck, and they are all fundamentally different. I need to represent them in prefixFlags, which is across the board stored as int, pictured here:

The last 4 are added by me. Annoyingly, the third one, NULLCHK, overflows int data type, so either I need to drop support for one of the options or the enum needs to be promoted to __int64 or similar. This is my first time doing any contribution to the JIT so I have no clue whether that is ok or who to ask if it is, so any advice appreciated

[AndyAyersMS]

We should be able to represent 32 flags in an int, not 8. Can't you use a 0x2, 0x4, or 0x8 based value?

[ltrzesniewski]

Why is this written in hex in the first place? There must be a good reason as 0x100 is not the same as 1 << 2 and wastes space: you'd get room for 32 bits if you use 1 << 0, 1 << 1, 1 << 2 and so on...

[john-h-k]

I am appalled i did not notice a) it was in hex and b) if that was binary there would be values left over. Thanks for the help, but sorry for the appallingly stupid question 😂