Fix SuperFileCheck from failing outerloop

[TIHan]

Resolves: #88622

Will need to run outerloop to double check.

[TIHan]

/azp run coreclr-release-outerloop-nightly

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[TIHan]

/azp run coreclr-release-outerloop

[azure-pipelines]

No pipelines are associated with this pull request.

[TIHan]

@dotnet/jit-contrib this is ready. The release-outerloop-nightly is failing due to an access-token so I can't be sure it fixes that pipeline.

[AndyAyersMS]

@TIHan I am seeing odd errors now from file-check tests, might it be this change?

[https://helixre107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-pull-88749-merge-f99c6104f5a341dc9c/JIT.opt/1/console.c1083330.log?helixlogtype=result

shows the add bit is now matching in the symbol table part of the dump:

[MethodImpl(MethodImplOptions.NoInlining)]staticsbyteInt8_Add(sbytex,sbytey){// X64-NOT: movsx// X64: add// X64-NEXT: movsxreturn(sbyte)(x+y);}

__tmp0_IntAdd.cs:18:15: error: X64-NEXT: is not on the line after the previous match
// X64-NEXT: movsx
^
__jit_disasm.out:20:2: note: 'next' match was here
movsx rax, cl
^
__jit_disasm.out:12:74: note: previous match ended here
;# V02 OutArgs [V02 ] ( 1, 1 ) struct ( 0) [rsp+00H] do-not-enreg[XS] addr-exposed "OutgoingArgSpace"
^
__jit_disasm.out:13:1: note: non-matching line after previous match is here
;
^

[markples]

Yes, this analysis is correct. By checking for "Lcl frame size" we skip past the preamble. It turns out that "add" is a fragile pattern. Maybe something like add .,. (with the appropriate filecheck regex wrapping) would suffice. Better would be a register pattern (looks like the test is trying to not hardcode a specific register), but of course those are annoying to write. When I played with the large-scale diffing, I introduced a notion of shortcuts so that one could put "reg" in the pattern and have it expanded by the tool to something more complicated. Theoretically, superfilecheck could do this, but it's kind of a pain and would increase our distance of standard filecheck.

[markples]

It looks like the test failure here got lost in all of the other failures.

[markples]

I'm on a different schedule and won't be able to see this through until much later, but if there isn't an immediate fix then this should be reverted because it impacts CI itself. Or maybe a known build error but it seems like it should be fixed rather than labeled.