[Openmcl-devel] Optimization and safety declarations

[Gary Byers]

On Wed, 21 Jan 2004, Gary Byers wrote:

>
>
> 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
> >

As it turns out, there were two bugs here, and the more aggressive
optimization setting didn't directly have much to do with anything.
(It could fail under (SAFETY 1) and work correctly under (SAFETY 0),
but was probably a bit less likely to do so).  Both of the bugs caused
the compiler's notion of what FP regs were (or could be) used in a linear
sequence of instructions to be incorrect; it was often too broad, but
some types of instructions that could modify FP regs were not marked
as doing so.