[Wasm RyuJIT] Set wasm's vector width to 128 bits

[kg]

This fixes a late compilation failure in crossgen when doing dependency analysis for Vector<T> in S.P.CoreLib:

Unhandled exception. System.InvalidOperationException: Operation is not valid due to the current state of the object.
   at Internal.TypeSystem.LayoutInt.get_AsInt()
   at Internal.JitInterface.WasmLowering.LowerToAbiType(TypeDesc type)
   at Internal.JitInterface.WasmLowering.GetSignature(MethodSignature signature, LoweringFlags flags)
   at Internal.JitInterface.WasmLowering.GetSignature(MethodDesc method)
   at ILCompiler.DependencyAnalysis.NodeFactory.WasmTypeNode(MethodDesc method)
   at ILCompiler.DependencyAnalysis.ObjectNode.GetStaticDependencies(NodeFactory factory)
   at ILCompiler.DependencyAnalysisFramework.DependencyAnalyzer`2.GetStaticDependenciesImpl(DependencyNodeCore`1 node)
   at ILCompiler.DependencyAnalysisFramework.DependencyAnalyzer`2.ComputeMarkedNodes()
   at ILCompiler.ReadyToRunCodegenCompilation.Compile(String outputFile)
   at ILCompiler.Program.RunSingleCompilation(Dictionary`2 inFilePaths, InstructionSetSupport instructionSetSupport, String compositeRootPath, Dictionary`2 unrootedInputFilePaths, HashSet`1 versionBubbleModulesHash, ReadyToRunCompilerContext typeSystemContext, Logger logger) in Z:\runtime\src\coreclr\tools\aot\crossgen2\Program.cs:line 669
   at ILCompiler.Program.Run() in Z:\runtime\src\coreclr\tools\aot\crossgen2\Program.cs:line 314
   at ILCompiler.Crossgen2RootCommand.<>c__DisplayClass217_0.<.ctor>b__0(ParseResult result) in Z:\runtime\src\coreclr\tools\aot\crossgen2\Crossgen2RootCommand.cs:line 274
   at System.CommandLine.Invocation.InvocationPipeline.Invoke(ParseResult parseResult)
   at ILCompiler.Program.Main(String[] args) in Z:\runtime\src\coreclr\tools\aot\crossgen2\Program.cs:line 946

Also includes a related change Andy suggested to disable being optimistic about instruction sets, since we don't have a Wasm client-side jit.

See also #125756

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Sets the WebAssembly (Wasm32) target’s Vector<T> SIMD width to a concrete 128-bit size during toolchain compilation, avoiding LayoutInt.AsInt failures (indeterminate size) when crossgen2 computes Wasm signatures and dependency analysis for Vector<T>.

Changes:

• Update InstructionSetSupport.GetVectorTSimdVector() to return SimdVectorLength.Vector128Bit for TargetArchitecture.Wasm32 (previously None).

[kg]

@dotnet/jit-contrib PTAL

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

src/coreclr/tools/aot/crossgen2/Program.cs:95

• The rationale here (“no Wasm client-side jit”) seems to apply to WASI targets as well. As-is, allowOptimistic will remain enabled by default for TargetOS.Wasi, which can reintroduce the same class of issues this change is trying to avoid. Consider extending the condition to include TargetOS.Wasi (or basing it on targetArchitecture == TargetArchitecture.Wasm32 rather than OS).

            if (targetOS is TargetOS.iOS or TargetOS.tvOS or TargetOS.iOSSimulator or TargetOS.tvOSSimulator or TargetOS.MacCatalyst or TargetOS.Browser)
            {
                // These platforms do not support jitted code, so we want to ensure that we don't
                // need to fall back to the interpreter for any hardware-intrinsic optimizations.
                // Disable optimistic instruction sets by default.
                allowOptimistic = false;

[AndyAyersMS]

@davidwrighton @tannergooding any thoughts on whether we should try to model Wasm features like we do ISA extensions for native targets?

We have #122309 / #122311 for keeping track of a baseline feature set, and currently no plans to opt in to anything beyond that, so a more detailed modelling may be premature.

[kg]

The main opt-in "feature" flag I can think of is multithreading. JS Promise Integration for async is another possibility, though that seems really hairy. Years from now we might want to use wide arithmetic and half-precision float support, which are making their way slowly through the spec process but don't have implementations.

[tannergooding]

@davidwrighton @tannergooding any thoughts on whether we should try to model Wasm features like we do ISA extensions for native targets?

I think it depends on how they operate, whether they are static for the lifetime of the program, and how we expect WASM output to operate in the scenario where such features are available/unavailable.

[SingleAccretion]

any thoughts on whether we should try to model Wasm features like we do ISA extensions for native targets?

Yes, we do want to model them as ISAs (we have no other mechanism to represent this).

I think it depends on how they operate, whether they are static for the lifetime of the program, and how we expect WASM output to operate in the scenario where such features are available/unavailable.

They are a bit special in that you can't emit 'dynamically' feature-using code, since the whole binary is validated for supported features eagerly. So it's a bit like the VEX encoding.