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.
Reviewed-by: Herb Derby <email@example.com>
Commit-Queue: Mike Klein <firstname.lastname@example.org>
1 file changed