diff options
author | Thomas Lively <7121787+tlively@users.noreply.github.com> | 2022-06-14 07:38:56 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2022-06-14 07:38:56 -0700 |
commit | 79211c2726f57e1d8a10733e2e130fa8b2543606 (patch) | |
tree | 3dfd4ad163ea04d9048d2e941f4d25de6ed46243 /src/passes/SignatureRefining.cpp | |
parent | 0657f612ce6fcbe8165d9f41c3e730273a9c7c64 (diff) | |
download | binaryen-79211c2726f57e1d8a10733e2e130fa8b2543606.tar.gz binaryen-79211c2726f57e1d8a10733e2e130fa8b2543606.tar.bz2 binaryen-79211c2726f57e1d8a10733e2e130fa8b2543606.zip |
[NFC] Optimize non-equirecursive LUB calculations (#4722)
Equirecursive LUB calculations potentially require building new recursive heap
types that did not already exist in the system, so they have a complicated code
path that uses a TypeBuilder to construct a LUB from the ground up. In contrast,
nominal and isorecursive LUB calculations never introduce new heap types, so
computing their LUBs is much simpler. Previously we were using the same code
path with the TypeBuilder for all type systems out of convenience, but this
commit factors out the LUB calculations for nominal and isorecursive types into
a separate code path that does not use a TypeBuilder.
Not only should this make LUB calculations faster for GC workloads, it also
avoids a mysterious race condition during parallel LUB calculations with
isorecursive types that resulted in a temporary type escaping from one thread
and being used-after-free from another thread. It would be good to fix that bug
properly, but it is very difficult to investigate. Sweeping it under the rug
instead is the best trade off for now.
Fixes #4719.
Diffstat (limited to 'src/passes/SignatureRefining.cpp')
0 files changed, 0 insertions, 0 deletions