runtime: The "no." opcode prefix is not implemented
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:
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
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 10
- Comments: 41 (39 by maintainers)
Commits related to this issue
- Add support for IL `no.` instruction prefix Related to #17469. Adds support for the IL `no.` prefix, which hints to the JIT to ignore certain checks. Currently implemented as a nop (which is ECMA335 ... — committed to john-h-k/coreclr by john-h-k 5 years ago
- WIP - omit rangechecks for no. prefixes WIP - Attempting to remove array bound checks in certain cases when `no. rangecheck` is specified. Part of fix to #17469 — committed to john-h-k/coreclr by john-h-k 5 years ago
- Add support for IL `no.` instruction prefix Related to #17469. Adds support for the IL `no.` prefix, which hints to the JIT to ignore certain checks. Currently implemented as a nop (which is ECMA335 ... — committed to AndyAyersMS/coreclr by john-h-k 5 years ago
- WIP - omit rangechecks for no. prefixes WIP - Attempting to remove array bound checks in certain cases when `no. rangecheck` is specified. Part of fix to #17469 — committed to AndyAyersMS/coreclr by john-h-k 5 years ago
- Add support for IL `no.` instruction prefix Related to #17469. Adds support for the IL `no.` prefix, which hints to the JIT to ignore certain checks. Currently implemented as a nop (which is ECMA335 ... — committed to AndyAyersMS/coreclr by john-h-k 5 years ago
- WIP - omit rangechecks for no. prefixes WIP - Attempting to remove array bound checks in certain cases when `no. rangecheck` is specified. Part of fix to #17469 — committed to AndyAyersMS/coreclr by john-h-k 5 years ago
Yes, a good first step would be to recognize and ignore the prefix. I would suggest being permissive in what you accept as any future extensions will likely have the “optional / hint” flavor to them too. So ignoring bits that are unspecified would be ok.
After that I would suggest working up a good set of test cases, and think through what should happen on them. Especially things like CSE candidates that differ only in
noprefixes; we would want to make sure we handle the combinatorics properly (see for instance the recent work we have done for value numbering and exceptions: dotnet/coreclr#20129).Perhaps? It is not clear this is something the jit can rely on. And there are potentially other challenges: attribute recognition at jit time is expensive, and we may end up stripping this attribute away in implementation assemblies, at least in some cases.
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.