skia /
skia /
5e09432f4f0da7d92b3bdc6ed253f9ffc278d3ca 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>
1 file changed
