…sis (#124416)

Implement codegen for
* GT_INDEX_ADDR (no bounds check case)
* GT_LEA
* GT_MEMORYBARRIER (no-op)
* GT_RETFILT

Add an SPMI workaround for type symbol lookup.

Relax some checks that assume try regions remain contiguous.

Add host (vm, crossgen) logic to classify structs per the Wasm Basic C
ABI.

Add calls in the JIT when targeting Wasm; also add extra calls under
SPMI when not targeting Wasm, so we can continue to use cross-jitting to
help test Wasm bring-up.

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…ly parsing (#124142)

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: jeffhandley <1031940+jeffhandley@users.noreply.github.com>
Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>
Co-authored-by: Stephen Toub <stoub@microsoft.com>
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…ation of LIFO policy. (#123921)

Re: #123159

Changes:
- Correctly handle `Backoff.Exponential(0)`. 

Embarrassing bug.  
To get exponentially growing random spin count for an iteration we
generate pseudorandom `uint` and do `>> (32 - attempt)`. Since C# masks
the shift operand with 31, when `attempt==0` we end up not shifting at
all, and the first iteration gets a large random spin count.
That caused many noisy results and interestingly some improvements (in
scenarios that benefit from very long spins).

- Unified implementation of LIFO policy with lightweight minimal
implementation of LIFO waiting.

Once we are done spinning, we block threads and when workers are needed
again wake them in LIFO order.

Unix WaitSubsystem is pretty heavy for these needs. It supports
Interruptible waits, waiting on multiple objects, etc... None of that is
interesting here. Most calls into the subsystem take a global
process-wide lock which can contend under load with other uses, or a
worker-waking threads may contend with the workers going to sleep,
etc...

Windows used an opaque `GetQueuedCompletionStatus` for the side effect
of releasing threads in LIFO order when completion is posted, with
unknown overheads and interactions, even though typically it is more
efficient than Unix WaitSubsystem.

The portable implementation seems to be faster than either of the
platform-specific ones.
(measured by disabling spinning and running a few latency-sensitive
benchmarks).

The portable implementation is also easier to reason about and to debug
anomalies.

- Adaptive spinning in the threadpool based on estimates of CPU core
availability.

Spinning in threadpool is very tricky and spinning benefits differ
greatly between scenarios. For some scenarios the longer the spin the
better. But there are scenarios that benefit when the threadpool
releases cores quickly once it sees no work. No preset fixed spin count
is going to be good for everything.

Adaptive approach appears to be necessary to improve some scenarios
without regressing many others.
We can further improve the heuristic, if there are more ideas.

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>