JIT: Make JIT time constants from calls to Type methods and properties

[omariom]

If JIT could treat the calls like typeof(T).IsValueType, typeof(IInterface).IsAssingnableFrom(typeof(T)) etc. as JIT time constants that could allow us to write more performant generic code.

category:cq
theme:type-intrinsics
skill-level:intermediate
cost:large

[mikedn]

Hmm, what would be the use of typeof(IInterface).IsAssingnableFrom(typeof(T) in generic code?

Test if a value type implement a certain interface? But if it does you'll probably need to cast to that interface anyway.

[omariom]

@mikedn
For example, we could use the trick EqualityComparer uses to dispatch handling to proper methods without casting and boxing.
Like this:

if (typeof(IInterface1).IsAssigneableFrom(typeof(T)))
{
      DispatcherForIInterface1.Instance.Dispatch(value);
}
else if (typeof(IInterface2).IsAssigneableFrom(typeof(T)))
{
    DispatcherForIInterface2.Instance.Dispatch(value);
}
else
{
     throw new Exception("Bad type.");
}

[mikedn]

I see. With this type of optimizations the JIT could reduce EqualityComparer<int>.CreateComparer() to just return new GenericEqualityComparer<int>();. And similar code size reductions could also be obtained for nullable and enum types. Even for reference types some size reductions could be obtained if the JIT knows that reference types cannot be enums nor nullables.

[mikedn]

While we're at it I think we can also add the case of

if (typeof(T) == typeof(int)) {...

The if is eliminated as expected when T is a value type other than int but it is not eliminated when T is a reference type (obviously, if T is a reference type it can never be int).

[benaadams]

👍

[benaadams]

Although for coreclr you need to do

typeof(T).GetTypeInfo().IsValueType
typeof(IInterface).GetTypeInfo().IsAssignableFrom(typeof(T).GetTypeInfo())

[omariom]

Nice property is that the optimizations won't disappear when Ngen'ed or .NetNative'ed, will they?

[mikedn]

Although for coreclr you need to do...

Yep, GetTypeInfo might complicate things a bit but hopefully not make it impossible. For typeof the return is likely always a RuntimeType.

Nice property is that the optimizations won't disappear when Ngen'ed or .NetNative'ed, will they?

At least the most useful one should stay. typeof(int).IsValueType must always return true but perhaps for typeof(SomeThirdPartyValueType).IsValueType runtime evaluation would be needed in case the type is changed to a reference type (though such a change would probably invalidate the native image).

[mikedn]

Maybe a table with various type methods and properties would be useful to look at. It's not exhaustive (I skipped many things that are unlikely to be useful or just too complex).

Member	Notes
BaseType	typeof(int).BaseType.IsValueType is always false for example. Unlikely to be very useful
GetEnumUnderlyingType	Could be useful to implement an efficient Enum.HasFlag<T>
GetTypeCode	Type.GetTypeCode(typeof(int)) is always TypeCode.Int32. Could be useful to replace a bunch of ifs with a switch.
IsAbstract	typeof(int).IsAbstract is always false. Doesn't seem useful
IsArray	typeof(int).IsArray is always false. Doesn't seem useful
IsAssignableFrom	Already discussed
IsClass	typeof(int).IsClass is always false. Similar to IsValueType but I'd say IsValueType is more common
IsEnum	typeof(SomeEnumType).IsEnum is always true. Seen in the CreateComparer method mentioned previously
IsPrimitive	typeof(int).IsPrimitive is always true. Might be useful sometimes
IsSealed	typeof(int).IsSealed is always true. Doesn't seem useful
IsSubclassOf	Somewhat similar to IsAssignableFrom but seems far less useful
IsValueType	Already mentioned

[omariom]

And.. cough.. typeof(T).ContainsReferences if it happens to be implemented 😉

[mikedn]

And.. cough.. typeof(T).ContainsReferences if it happen to be implemented 😉

Indeed 😄

And there's another thing that's not directly related to Type properties:

        static void Test<T>(T x)
        {
            if (x is int)
            {
                Console.WriteLine("sure it is");
            }
        }

For T = int the type check should be a no-op but in reality it does boxing. AFAIR that's what you were trying to avoid in corefxlab's AppendUntyped PR.

[omariom]

It is even more readable than typeof(T) == typeof(int).

[omariom]

@mikedn
To sum up that scenario.

In these cases, given value is of generic type T and the code is value type instantiated, JIT could call the methods without boxing, inlining them if appropriate.

// 1. Currently boxes value on each comparison and casting to object.
if (value is IInterface)
{
     ((IInterface)(object)value).Method();
}
else if (value  is IAnotherInterface)
{
      ((IAnotherInterface)(object)value).Method2();
}

// 2. Variation of the  previous one.
if (typeof(IInterface).IsAssingnableFrom(typeof(T))
{
     ((IInterface)(object)value).Method();
}
else typeof(IAnotherInterface).IsAssingnableFrom(typeof(T)
{
      ((IAnotherInterface)(object)value).Method2();
}

Here JIT could avoid boxing as well. Currently it boxes once per comparison.

if (value is int)
{
     int intValue = (int)(object)value);
}
else if (value  is long)
{
      long longValue = ((long)(object)value);
}

[mikedn]

JIT could call the methods without boxing, inlining them if appropriate.

Are you talking about calls to Method and Method2? Yes, boxing could be avoided there but note that the JIT would need to make a copy of the value before calling. That may limit the usefulness of such code.

[omariom]

Because boxing implies making a copy?
Even if so not boxing and inlining save much more.
And for primitives copying is no op, isn't it?