[Openmcl-devel] Optimization and safety declarations

[Gary Byers]

On Wed, 21 Jan 2004, Raffael Cavallaro wrote:

> I've come across a benchmark on the net that determines whether a point
> is in a polygon. I've appended the source below. It's also available
> at:
> <http://openmap.bbn.com/~kanderso/performance/postscript/in-poly.ps>
> (see page 5 for lisp source)
>
> When compiled with:
> (declare (optimize (speed 3) (safety 0))…
> it generates fast code, but the result is wrong - the final output
> should be 60000, but it returns 80000 with safety 0.
> (declare (optimize (speed 3) (safety 1))…
> generates code that takes about 50% longer to run, and produces the
> correct result. All of these optimization settings refer to the first
> function, pnpoly, not the test function, pnpolytest.
> I've looked at the disassembly, but, to be honest, I can't tell why it
> is that the generated code is incorrect for the safety 0 optimization
> declaration - (this should be unsurprising because I know next to
> nothing about reading lisp disassembly).
>
> What is OpenMCL doing when safety is declared 0, that causes incorrect
> code to be generated? Is this just a risk of using the safety 0
> setting, or is this some sort of bug in OpenMCL's code generation? BTW,
> sbcl is just as fast with safety 0 as OpenMCL, but generates correct
> code, at least to judge from the output.
> TIA,
> raf
>

The only differences that're supposed to be there is whether AREF does
as much type- and bounds-checking; if the generated code was correct,
you -might- find that the unsafe version was very slightly faster.
(Determining whether the array's really a (SIMPLE-ARRAY DOUBLE-FLOAT (*))
and determining whether or not an index is in bounds are both fairly
cheap operations.)

The bug seems to be in some code that tries to eliminate some extra
pushing and popping in the intermediate code; it's not immediately
clear to me why that code fails in FNPOLY's case and not in simpler
test cases, but the safe version (with extra bounds and type checking)
uses registers differently (and generates different control-flow
instructions) than the unsafe version and is apparently less likely to
trigger the bug.  (I don't yet know exactly what -does- trigger the bug.)