Don't create a constant node for Vector64

[tannergooding]

This fixes #105537

[tannergooding]

@matouskozak, is there a way to kick of the job that failed for #105537?

edit: Found the command, I had missed that this was just extra-platforms, I had misclicked and couldn't find the job name initially

[tannergooding]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

@matouskozak, is there a way to kick of the job that failed for #105537?

edit: Found the command, I had missed that this was just extra-platforms, I had misclicked and couldn't find the job name initially

Yes, extra-platforms is fine. You can also use just runtime-ioslike which will trigger the tvos-arm64 job that is failing.

[dotnet-policy-service]

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

[tannergooding]

Looks like there's a non-trivial number of failures in the regular runs that are independent of the break found in #105537

Going to try and see if I can discern what's existing and what's new. Will end up putting a PR up to revert the change if this isn't trivial to resolve

[matouskozak]

Looks like there's a non-trivial number of failures in the regular runs that are independent of the break found in #105537

Going to try and see if I can discern what's existing and what's new. Will end up putting a PR up to revert the change if this isn't trivial to resolve

I'll help with that after the run finishes. The mobile-related failures are tracked at #103472 which should help with discerning what's related.

[matouskozak]

Looks like there's a non-trivial number of failures in the regular runs that are independent of the break found in #105537
Going to try and see if I can discern what's existing and what's new. Will end up putting a PR up to revert the change if this isn't trivial to resolve

I'll help with that after the run finishes. The mobile-related failures are tracked at #103472 which should help with discerning what's related.

I took a brief look and the System.Runtime.Intrinsics.Tests are no longer failing on tvos-arm64 job. However, the Microsoft.Bcl.Memory.Tests still do, crash dump. I think this failure could still be related, right?

[tannergooding]

However, the Microsoft.Bcl.Memory.Tests still do, crash dump. I think this failure could still be related, right?

Could be as there weren't any changes to Base64UrlDecoder in the past few days, but Base64Decoder isn't actually using Vector128.Shuffle anywhere, notably. It's also a bit odd that only these tests are failing and only on this one platform.

The log doesn't appear to have any meaningful stack trace, all just indicating something fails in reflection as part of InterpretedInvoke_Method. Base64Decoder then uses a SimdShuffle helper that defers down to Vector128.ShuffleUnsafe which itself defers down to AdvSimd.Arm64.VectorTableLookup, so it "shouldn't" be hitting this code path anywhere.

Is there an easy way to get additional information/context for the failure here?

[steveisok]

Is there an easy way to get additional information/context for the failure here?

Is there an actual crash in Microsoft.Bcl.Memory.Tests suite? I don't see it from the logs.

Given there are individual test failures, I would recommend running it local on an ios device and see if you can and debug. If you don't have a device, I'm sure @matouskozak could help. I don't think the failure is exclusive to tvOS (we only run a subset on ios).

[tannergooding]

Is there an actual crash in Microsoft.Bcl.Memory.Tests suite? I don't see it from the logs.

I don't either, just the 8 test failures failing from an xunit assert.

If you don't have a device, I'm sure @matouskozak could help.

I don't have such a device, unfortunately. So any help getting a better log, disassembly, LLVM IR, etc would be appreciated

[tannergooding]

This was the remaining issue.

Mono only supports 128-bit xconst today, but we're still trying to handle the case where only some inputs are constant; such as Vector128.Create(1, 2, x, 4). This was early exiting in the case that not all inputs were constant so in the main loop below we ended up getting Vector128.Create(1, 2, x, 0) instead.

Fixed it to not early exit and only skip parameters if some were constant; which lets us get the correct value instead.

[tannergooding]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).