tree fb8e8280856386748468c0aa3e36974b352c093d
parent afaf5d56c583838e038d8f9a786be0360d08f432
author Mike Klein <mtklein@google.com> 1593536854 -0500
committer Skia Commit-Bot <skia-commit-bot@chromium.org> 1593540907 +0000

careful constants map handling

Setting up the Windows JIT made me notice that we can
modify the constants SkTHashMap while using it, e.g.

   a->vfmaddps132(dst(x), reg(y), any(z))

if any() returns a Label* Operand pointing to a constant, and
reg() needs to load from a constant too, and the second to touch
the constants map causes a hash table resize, the other is left
with a Label* that's pointing into the old table.

The fix is to (mostly) never modify the constants table when
looking up constants, instead using the Op::splat to seed the
table.  A couple miscellaneous constants like 0xffff'ffff as
used by assert_true are not dangerous so I've left them alone.

This is the sort of bug ASAN would catch, except we turn off
the JIT when building for ASAN.  I think I can tighten that up
so that we still JIT under ASAN, but never use the JIT'd code.
That'd let us catch bugs like this in the JIT itself.

Change-Id: I91d8f6fda721a6e3c9e3629d694a73fd1b2bf8f1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/299879
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>