checked and unchecked blocks don't appear at the IL level. They are only used in the C# source code to tell the compiler whether or not to pick the checking or non-checking IL instructions when overriding the default preference of the build configuration (which is set through a compiler flag).
Of course, typically there will be a performance difference due to the fact that different opcodes have been emitted for the arithmetic operations (but not due to entering or exiting the block). Checked arithmetic is generally expected to have some overhead over corresponding unchecked arithmetic.
As a matter of fact, consider this C# program:
class Program
{
static void Main(string[] args)
{
var a = 1;
var b = 2;
int u1, c1, u2, c2;
Console.Write("unchecked add ");
unchecked
{
u1 = a + b;
}
Console.WriteLine(u1);
Console.Write("checked add ");
checked
{
c1 = a + b;
}
Console.WriteLine(c1);
Console.Write("unchecked call ");
unchecked
{
u2 = Add(a, b);
}
Console.WriteLine(u2);
Console.Write("checked call ");
checked
{
c2 = Add(a, b);
}
Console.WriteLine(c2);
}
static int Add(int a, int b)
{
return a + b;
}
}
This is the generated IL, with optimizations turned on and with unchecked arithmetic by default:
.class private auto ansi beforefieldinit Checked.Program
extends [mscorlib]System.Object
{
.method private hidebysig static int32 Add (
int32 a,
int32 b
) cil managed
{
IL_0000: ldarg.0
IL_0001: ldarg.1
IL_0002: add
IL_0003: ret
}
.method private hidebysig static void Main (
string[] args
) cil managed
{
.entrypoint
.locals init (
[0] int32 b
)
IL_0000: ldc.i4.1
IL_0001: ldc.i4.2
IL_0002: stloc.0
IL_0003: ldstr "unchecked add "
IL_0008: call void [mscorlib]System.Console::Write(string)
IL_000d: dup
IL_000e: ldloc.0
IL_000f: add
IL_0010: call void [mscorlib]System.Console::WriteLine(int32)
IL_0015: ldstr "checked add "
IL_001a: call void [mscorlib]System.Console::Write(string)
IL_001f: dup
IL_0020: ldloc.0
IL_0021: add.ovf
IL_0022: call void [mscorlib]System.Console::WriteLine(int32)
IL_0027: ldstr "unchecked call "
IL_002c: call void [mscorlib]System.Console::Write(string)
IL_0031: dup
IL_0032: ldloc.0
IL_0033: call int32 Checked.Program::Add(int32, int32)
IL_0038: call void [mscorlib]System.Console::WriteLine(int32)
IL_003d: ldstr "checked call "
IL_0042: call void [mscorlib]System.Console::Write(string)
IL_0047: ldloc.0
IL_0048: call int32 Checked.Program::Add(int32, int32)
IL_004d: call void [mscorlib]System.Console::WriteLine(int32)
IL_0052: ret
}
}
As you can see, the checked and unchecked blocks are merely a source code concept - there is no IL emitted when switching back and forth between what was (in the source) a checked and an unchecked context. What changes is the opcodes emitted for direct arithmetic operations (in this case, add and add.ovf) that were textually enclosed in those blocks. The specification covers which operations are affected:
The following operations are affected by the overflow checking context established by the checked and unchecked operators and statements:
- The predefined ++ and -- unary operators (§7.6.9 and §7.7.5), when the operand is of an integral type.
- The predefined - unary operator (§7.7.2), when the operand is of an integral type.
- The predefined +, -, *, and / binary operators (§7.8), when both operands are of integral types.
- Explicit numeric conversions (§6.2.1) from one integral type to another integral type, or from float or double to an integral type.
And as you can see, a method called from a checked or unchecked block will retain its body and it will not receive any information about what context it was called from. This is also spelled out in the specification:
The checked and unchecked operators only affect the overflow checking context for those operations that are textually contained within the “(” and “)” tokens. The operators have no effect on function members that are invoked as a result of evaluating the contained expression.
In the example
class Test
{
static int Multiply(int x, int y) {
return x * y;
}
static int F() {
return checked(Multiply(1000000, 1000000));
}
}
the use of checked in F does not affect the evaluation of x * y in Multiply, so x * y is evaluated in the default overflow checking context.
As noted, the above IL was generated with C# compiler optimizations turned on. The same conclusions can be drawn from the IL that's emitted without these optimizations.
