Re: Apparent optimiser bug breaks compiled code (2.1.0-alpha)
- From: Mike Pall <mike-1410@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 8 Oct 2014 22:14:02 +0200
Alexander Gall wrote:
> In the current state, the calculation of the hash of the input
> data starts to fail when the code is optimizied, but strangely enough
> only if the profiler is enabled with the 'l' option as well:
I've found a problem with fused loads of constants under high
register pressure.
Thank you for the test case! Fixed in the git repository.
> A remark about the Bloom filter code: it contains loops with a low
> number of iterations (4 in this example), which is fixed and known
> when the filter is created. The code uses an automated "loop unroller"
> to, well, unroll these loops. This hack has sped up processing
> considerably (avoidance of trace aborts due to loop unrolling by the
> compiler and improved optimizaton to eliminate GC overhead). I'd be
> interested to learn whether that's actually a good thing to do or has
> any drawbacks (like causing the effect I'm seeing here ;)
Well ... high register pressure, lots of spills etc.
But the code isn't optimal, anyway. Too many abstractions, lots of
tiny details (e.g. that multiply by 16 goes via FP). You should
always have a close look at the generated IR and assembler code,
if you're doing performance tuning at that level.
--Mike
Other related posts:
