Re: Apparent optimiser bug breaks compiled code (2.1.0-alpha)
- From: Mike Pall <mike-1409@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Tue, 30 Sep 2014 14:16:27 +0200
Alexander Gall wrote:
> The manner in which the hash value is stored and accessed from the loop may
> look weird, but it should work correctly when compiled nevertheless, I
> believe.
Nope, you're violating the strict aliasing rules. You're storing
via a 64 bit pointer and loading via another 32 bit pointer. The
compiler is free to optimze out your 32 bit check.
Use a union and consistently dereference from the _same_ variable
that holds the union. That's the only allowed exception from the
strict aliasing rules. E.g.: uu.u64[0] = x; y = uu.u32[0]
Also, you should read up on the Lua BitOp semantics. You never
need a 'band(expr, max64)'. You either pass the expression to the
next bit operation, which performs the coercion, anyway. Or use
tobit() if it's not a bit operation.
Also, since you're using 64 bit cdata numbers: they already wrap
around on overflow and they don't have the range problem with
multiplication, either. And you should initialize h1, h2, k1, k2
with 0ULL and not 0, which avoids coercion issues, too.
--Mike
Other related posts:
