[ilasm] Lazily allocate memory in Indx256

[markples]

Indx256 is a trie (or prefix tree) used to map labels to instructions. It is very space-intensive because it allocates 256-element arrays for child nodes. This is a localized fix to lazily allocate the child arrays and to split them into two 128-element arrays to handle common cases such as ildasm's output (IL_). A more aggressive change to a different data structure would save much more memory but should probably include an analysis of why a trie was originally used.

Fixes #38515, #38529, #43818, and #73139. I don't think hugeExpr1 (#38515) is going to get picked up by our current testing since the ilasmroundtrip run doesn't turn off tiered compilation, but I did check its behavior on x86 locally.

[ghost]

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

Issue Details

---

Indx256 is a trie (or prefix tree) used to map labels to instructions. It is very space-intensive because it allocates 256-element arrays for child nodes. This is a localized fix to lazily allocate the child arrays and to split them into two 128-element arrays to handle common cases such as ildasm's output (IL_). A more aggressive change to a different data structure would save much more memory but should probably include an analysis of why a trie was originally used.

Fixes #38515, #38529, #43818, and #73139. I don't think hugeExpr1 (#38515) is going to get picked up by our current testing since the ilasmroundtrip run doesn't turn off tiered compilation, but I did check its behavior on x86 locally.

Author:	markples
Assignees:	-
Labels:	area-ILTools-coreclr
Milestone:	-

[TIHan]

/azp run runtime-coreclr ilasmroundtrip

[azure-pipelines]

No pipelines are associated with this pull request.

[TIHan]

Good explanation of this.

[TIHan]

Changes make sense to me. Only thing left to do is run ilasmroundtrip pipeline, which, we will need to run it manually in azure devops.

[markples]

ilasmroundtrip had one failure that matches #76280

https://dev.azure.com/dnceng-public/public/_build/results?buildId=40034&view=results

https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-76590-merge-7401007fc42f47e7a1/JIT.HardwareIntrinsics.General.Vector256/1/console.e1969e3c.log?helixlogtype=result

Beginning test case Multiply.Int16 at 10/4/2022 7:17:32 PM
      Random seed: 20010415; set environment variable CORECLR_SEED to this value to repro
      
      Beginning scenario: RunBasicScenario_UnsafeRead
      Beginning scenario: RunReflectionScenario_UnsafeRead
      Vector256.Multiply<Int16>(Vector256<Int16>, Vector256<Int16>): RunReflectionScenario_UnsafeRead failed:
          left: (12349, 2077, 2517, 24831, 15335, 21277, 18310, 24742, 29224, 1501, 30542, 30209, 25839, 20619, 27223, 15463)
         right: (26331, 30859, 23718, 5423, 18949, 5399, 15719, 6382, 2686, 639, 9923, 32176, 9978, 23285, 4897, 26979)
        result: (-28113, -65, -5090, -17967, -3709, -10085, -19222, 27220, 0, 0, 0, 0, 0, 0, 0, 0)

Beginning test case Max.Double at 10/4/2022 7:17:29 PM
      Random seed: 20010415; set environment variable CORECLR_SEED to this value to repro
      
      Beginning scenario: RunBasicScenario_UnsafeRead
      Beginning scenario: RunReflectionScenario_UnsafeRead
      Vector256.Max<Double>(Vector256<Double>, Vector256<Double>): RunReflectionScenario_UnsafeRead failed:
          left: (0.30494365762218073, 0.8294232901322763, 0.3422121491014083, 0.7015113330918883)
         right: (0.4280050426851982, 0.980779036870589, 0.38619966916097315, 0.05648377959452745)
        result: (0.4280050426851982, 0.980779036870589, 0.38619966916097315, 0.05648377959452745)

[markples]

Other failures were two builds and a non-ilasm instance of #76280. Retrying.