Skip to content

Conversation

@anthonycanino
Copy link
Owner

I'm creating this PR so I have a place to document a few of the changes I've made and some of the existing issues.

Changes:

  1. Added various changes to the backend emitter to allow the upper simd registers to be encoded with EVEX. Some refactorings around instruction descriptor were required. Most of the changes were in emitxarch.cpp etc.
  2. Added xmm16 - xmm31 to associated register definition files (register.h and targetamd64.h). In addition, add a stress mode JitStressRegs=4 that will force the upper simd registers to be allocated. JitStressEVEXEncoding=1 must be enabled for the upper regs to be used.
  3. Adjusted the lsra build phases to specify when the lower simd registers must be used --- when a GT_NODE lowers to an instruction that does not have a compatible EVEX form, mm16-mm31 cannot be used for its registers. RBM_NONE is used as the mask during much of the lsra build phase, at which point a use will select the set of all registers available for a register type if RBM_NONE is specified (dotnet@f8a04a3#diff-ad66a6bcf1fd550d5ad10d995c03218afbbc39463d36e1f2a224f9ca070a2f99R560-R574).

Because of node containment, it wasn't so easy to specific the set of low simd registers during the lsra build code because a tbe build up of a contained node didn't necessarily use the same register set as its containing node (a limitation which is noted in the comment). I get around this with the RBM_LOWSIMD marker.

  1. I've added zmm16:zmm31 to the flt callee trash register set. Before I made this change, I was getting some issues with some functions using and not preserving the registers correctly.

  2. Because the set of available registers is now dependant upon available ISA and not arch, there is some code to adjust the available float registers based on the available AVX512 ISA. Likewise, I think a lot of the trash set macros needs to be adjusted as well (RBM_STOP_FOR_GC_TRASH as an example).

Currently, most of the JIT tests pass and no asserts on superpmi but quite a lot of diffs in the prolog/epilog.

@kunalspathak
Copy link

Currently, most of the JIT tests pass and no asserts on superpmi but quite a lot of diffs in the prolog/epilog.

Does this happen even if JitStressEVEXEncoding=0 or only when JitStressEVEXEncoding=1 and JitStressRegs=4?

anthonycanino pushed a commit that referenced this pull request Jul 6, 2023
…tnet#87189)

This fixes a startup crash on Big Sur:

> error: * Assertion at /Users/runner/work/1/s/src/mono/mono/utils/mono-hwcap-arm64.c:35, condition `res == 0' not met

Because sysctl can't find some of these options:

    $ sysctl hw.optional.armv8_crc32
    hw.optional.armv8_crc32: 1
    $ sysctl hw.optional.arm.FEAT_RDM
    sysctl: unknown oid 'hw.optional.arm.FEAT_RDM'
    $ sysctl hw.optional.arm.FEAT_DotProd
    sysctl: unknown oid 'hw.optional.arm.FEAT_DotProd'
    $ sysctl hw.optional.arm.FEAT_SHA1
    sysctl: unknown oid 'hw.optional.arm.FEAT_SHA1'
    $ sysctl hw.optional.arm.FEAT_SHA256
    sysctl: unknown oid 'hw.optional.arm.FEAT_SHA256'
    $ sysctl hw.optional.arm.FEAT_AES
    sysctl: unknown oid 'hw.optional.arm.FEAT_AES'

Full stack trace:

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
  * frame #0: 0x0000010ef37560 libmonosgen-2.0.dylib`monoeg_assertion_message
    frame #1: 0x0000010ef375cc libmonosgen-2.0.dylib`mono_assertion_message + 32
    frame #2: 0x0000010ef40d6c libmonosgen-2.0.dylib`mono_hwcap_arch_init + 544
    frame #3: 0x0000010ef54bd8 libmonosgen-2.0.dylib`mono_hwcap_init + 72
    frame #4: 0x0000010ee14dc0 libmonosgen-2.0.dylib`parse_optimizations + 52
    frame #5: 0x0000010edbed48 libmonosgen-2.0.dylib`mono_init
    frame #6: 0x0000010ee18968 libmonosgen-2.0.dylib`mono_jit_init_version
    frame #7: 0x0000010f48a300 libxamarin-dotnet-debug.dylib`xamarin_bridge_initialize + 216
    frame #8: 0x0000010f4900a4 libxamarin-dotnet-debug.dylib`xamarin_main + 376
anthonycanino pushed a commit that referenced this pull request Dec 18, 2024
* bug #1: don't allow for values out of the SerializationRecordType enum range

* bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type

* bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use)

* bug #4: document the fact that IOException can be thrown

* bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails

* bug #6: 0 and 17 are illegal values for PrimitiveType enum

* bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants