Re: GNU Guile branch, wip-peval-predicates, created. v2.0.5-100-g59c5570

[Andy Wingo]

Hi,

On Fri 13 Apr 2012 10:07, Mark H Weaver <address@hidden> writes:

> Nonetheless, the vtable checks involve comparisons with a mutable
> top-level variable.  Whenever unknown code is run (e.g. when a top-level
> procedure is called) you must assume the worst: that any top-level
> variable might have been 'set!'.

You probably saw, but wip-cse does effects analysis to prove that the
toplevel hasn't been set! by intervening expressions.

There is of course the question of what optimizations like this may be
made in the presence of concurrently executing threads.  For example, in
wip-cse the following expression folds:

  (if (eq? x y) (eq? x y) #f) => (eq? x y)

This is because there was no toplevel-set! in between the first and
second checks.  The possible side effects of referencing X or Y would
happen on the first check or not at all, so the second expression can
cause no effects.  (If CSE sees a call to an unknown procedure, it's
assumed that it can cause any effect, and thus such a call does not
commute with anything but a "constant" expression.)

But OK, the question here is, what if another thread is concurrently
mutating X and Y?  If this were C++ or Java, the answer would be that
they can still fold, because access to a multithreaded mutable needs to
be synchronized.  I think this is reasonable.  What do you think?

Andy
-- 
http://wingolog.org/