Test failure in JIT/jit64/opt/cse/HugeArray1/HugeArray1.sh

[v-haren]

failed in job: runtime-coreclr crossgen2 outerloop 20200222.1

Error message
\ncmdLine:/home/helixbot/work/B79909FA/w/BBBE0A3C/e/JIT/jit64/opt/cse/HugeArray1/HugeArray1.sh Timed Out\n\nReturn code: -100\nRaw output file: /home/helixbot/work/B79909FA/w/BBBE0A3C/e/JIT/jit64/Reports/JIT.jit64/opt/cse/HugeArray1/HugeArray1.output.txt\nRaw output:\nBEGIN EXECUTION\nin takeLock\nWarning: No files matching /home/helixbot/work/B79909FA/w/BBBE0A3C/e/JIT/jit64/opt/cse/HugeArray1/*.dll\n\ncmdLine:/home/helixbot/work/B79909FA/w/BBBE0A3C/e/JIT/jit64/opt/cse/HugeArray1/HugeArray1.sh Timed Out\nTest Harness Exitcode is : -100\nTo run the test:\n> set CORE_ROOT=/home/helixbot/work/B79909FA/p\n> /home/helixbot/work/B79909FA/w/BBBE0A3C/e/JIT/jit64/opt/cse/HugeArray1/HugeArray1.sh\nExpected: True\nActual: False

[davidwrighton]

This is caused by pathological behavior in Compiler::optValnumCSE_Index. In particular, the optCSEhash can grow an unbounded amount if the function has numerous trees which are put into the optCSEhash as possible CSE candidates, but fewer than MAX_CSE_CNT are found, then the compiler will spend excessive amounts of time looking up entries in the optCSEhash. I've prototyped a change which makes the optCSEhash grow its bucket count, which address the performance concern here. This issue only reproduces for this test when running crossgen2 with optimizations enabled. Also the slowdown has been much more visible on Linux. Presumably, that perturbs the codegen to some interesting degree.

In this particular case, the hashtable grows to over 524288 elements, and the current bucket count is 128, thus leading to significant slowdown.

With the prototype fix (PR #40056) compilation on my machine goes from 5 minutes to 9.5 seconds.