Add pointer overloads for Avx2.BroadcastScalarToVector256

[fiigii]

Match CoreCLR change dotnet/coreclr#20193

@CarolEidt @tannergooding @eerhardt

[fiigii]

@dotnet-bot test this please

[CarolEidt]

LGTM

[fiigii]

I have disabled the API baseline checks for the netcoreappaot in the previous PR. But Packaging All Configurations x64 Debug Build fails again here. What should I do for the test? cc @tannergooding @jkotas

[jkotas]

@fiigii Try to add the <RunApiCompat Condition="'$(TargetGroup)' != 'netcoreappaot'">true</RunApiCompat> condition directly to src/System.Runtime.Intrinsics/src/System.Runtime.Intrinsics.csproj to see whether it makes the errors go away.

If it does work, do the busy work to add the the errors to https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Intrinsics/src/ApiCompatBaseline.netcoreappaot.txt. It will make the errors go away for sure, but I would love to figure out a way how we can avoid doing this busy work for frequently changing assemblies like System.Runtime.Intrinsics.csproj.

cc @morganbr

[morganbr]

@jkotas, would it work/make sense to make System.Runtime.Intrinsics a partial façade with NotImplementedExceptions? I wonder if that would also be useful for all of the APIs that don't match a particular architecture.

[jkotas]

would it work/make sense to make System.Runtime.Intrinsics a partial façade with NotImplementedExceptions?

As a hack to make the error go away - yes.

As the proper solution for this case - no. The IsSupported properties need to return false, not throw exceptions.

[morganbr]

I think a partial façade can be implemented with whatever code that's useful (false for IsSupported, NotImplementedException for the intrinsics). @ericstj, does that sound right?

[jkotas]

I have misunderstood what you meant. I think you meant that the implementation may be coming either from CoreLib or CoreFX depending on the config. Yes, it would be possible in theory.

Having different implementation homes for given type based on config was pain to deal with. We got rid of all places that have done that - the legacy setup for S.P.Interop from ProjectN is the only one left.

[ericstj]

Cross compiling in corefx with partial impl in source is perfectly reasonable so long as you have a good pivot to cross-compile by.

[jkotas]

Cross compiling in corefx with partial impl in source is perfectly reasonable

We are talking about having different CoreLib public surface based on CPU architecture. We assume that the CoreLib surface is same between different CPU architectures today. If start having different CoreLib surface for different CPU architectures, anything that makes the assumption has to be forked. For example, configurations like https://github.com/dotnet/corefx/blob/master/src/System.Runtime/src/Configurations.props would have to be replicated 4 times for x86/x64/arm/arm64 to account for the differences; etc. I do not think we want to go there.

[morganbr]

I didn't mean to imply different surface based on CPU architecture, just on TargetGroup.

[morganbr]

Ok, apparently I did imply that, but I'm happy to drop the CPU part and settle for TargetGroup

[jkotas]

I'm happy to drop the CPU part and settle for TargetGroup

It would still not address the pain with iterating on System.Runtime.Intrinsics library.

[fiigii]

@jkotas I tried the two approaches you suggested, seems only the "busy work" works. Now CI gets green.

[jkotas]

Thanks