[Ecls-list] Feedback needed: more detailed optimization settings

[Juan Jose Garcia-Ripoll]

As I said, I am laying the foundations for the new compiler and at the same
time polishing what is being used right now.

One thing I have faced right now is a stupid problem with optimization
settings and ECL's optimizater policies.

Those policies are defined to some extent in the manual and are implemented
as a set of functions that query the compiler environment comparing SPEED,
SPACE and DEBUG settings and deciding based on that. See it here by yourself

http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=blob_plain;f=src/cmp/cmppolicy.lsp;hb=HEAD

I am not terribly happy with this, because the choices are somewhat ad-hoc,
largely motivated by compatibility with SBCL and the constraints imposed by
the specification.

For instance today I faced a problem with a function that was defined to
have SAFETY 0, to get the most of the inline forms of CAR, CDR, slot
accessors, etc, but then this causes the deactivation of the code that
checks the number of arguments.

It is for this reason that I am considering to include a set of extended
declarations, which would look as
   (DECLARE
     (EXT:POLICY-CHECK-ARGS)
     (EXT:POLICY-INLINE-SLOT-ACCESSORS NIL)
     ...)

The problem I am having right now is how to specify the interaction of these
flags (which could also appear in proclamations, DECLAIM, etc) with the
standard optimization settings. One possibility would be defining the whole
set of optimizations as a bitmap, B. Each of the standard optimization
settings would then do two things: first compute a combined mask of
optimizations that are activated, A, and a combined mask of flags that are
deactivated, D, and compute B <- (LOGANDC2 (LOGIOR B A) D)

It would then be easier to claim which optimizations get triggered by which
optimization settings and which ones get deactivated.

Does it make sense to you?

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100507/97806609/attachment.html>