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-by: Herb Derby <>
Commit-Queue: Mike Klein <>
1 file changed