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

Matthew Mondor mm_lists at pulsar-zone.net
Sat May 8 03:22:01 UTC 2010


On Fri, 7 May 2010 23:49:27 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

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

Although I don't consider myself as an authority on the matter, this
seems to make sense to me, not only so that there's no ambiguity in the
compiler code, but also in the documentation.

It reminds me of C compilers where -O<n> optimization settings are
presets which also may be altered by lower-level case-specific
optimization flags.  Of course, the various numbered levels should
probably still behave as close as possible to user expectations.

Now that I check the hyperspec about declarations there's also the
DECLARATION which would allow user code to also make use of
case-specific declarations which might have no effect on another
implementation (an alternative to #+ I guess in this case).  Which at
least acknowledges that an implementation is free to add custom
declaration facilities...
-- 
Matt




More information about the ecl-devel mailing list