Add JIT-helper of ArgTypeNotSupportedException

[fiigii]

Intel hardware intrinsics need to throw exceptions with System.NotSupportedException: Specified type is not supported on Vector128/256<T> that is instantiated by non-numeric types.

[fiigii]

@CarolEidt @jkotas Would you like to port this change to desktop CLR at first? I need this jit-helper in my Vector128/256<T> work.

[jkotas]

You will need to change JIT interface GUID at the top of corinfo..h for this change.

cc @dotnet/jit-contrib

[janvorli]

A nit - comment alignment

[fiigii]

Thank you, will fix.

[fiigii]

You will need to change JIT interface GUID at the top of corinfo..h for this change.

@jkotas I see. Shall I update GUID now? Or wait for the update from desktop CLR change?

[briansull]

Go ahead and make the GUID change as part of your checkin.

We will need to check in the src/inc/corinfo.h changes on the Desktop as a separate step.

[fiigii]

@briansull Got it, thank you.

[fiigii]

@dotnet-bot test OSX10.12 x64 Checked Innerloop Build and Test
@dotnet-bot test Tizen armel Cross Checked Innerloop Build and Test
@dotnet-bot test Ubuntu x64 Checked Innerloop Build and Test
@dotnet-bot test Ubuntu16.04 armlb Cross Debug Innerloop Build

[fiigii]

@jkotas The test failures look unrelated to this change?

[jkotas]

Actually, I do not think you need a helper for this. Why can't the jit fallback to the non-inlined implementation to throw the exception?

[fiigii]

Why can't the jit fallback to the non-inlined implementation to throw the exception?

@jkotas Do you mean something like this?

public static Vector128<T> GetLowerHalf<T>(Vector256<T> value) where T : struct 
{
    if (typeof(T) != typeof(Byte) && typeof(T) != typeof(UByte) && ... )
    {
        throw new NotSupportedException(SR.Arg_TypeNotSupported);
    }
    return GetLowerHalf<T>(value);
}

This is a good point. However, our current contract is "named intrinsics that directly called by itself must be expanded". If we add the exception code in the managed implementation, that would break this contract. Then other named intrinsics cannot have the fallback with any recursive algorithm in the future. I am afraid that might be a too strict limitation.

[jkotas]

Right, something like this.

I would think that gtIsRecursiveCall will still return true for the above case and the inner call will be force expanded. If there is something that I am missing, we should fix it.

[fiigii]

I would think that gtIsRecursiveCall will still return true for the above case and the inner call will be force expanded.

I meant maybe other recursive intrinsics (in the future) that we still want them optionally expanded and only "directly recursive" intrinsics are forced expanded.
But, at this time, your solution is reasonable to me. If you think we do not need to consider the above situation, I will close this PR.

[jkotas]

Right, I do not think we need to worry about it - until we have a real situation like that.