Re: optimization

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

josh wrote:
> [...]
> > Plain script code should not be affected (since one only rarely puts
> > in a deliberately unused side-effect-free expression).
> 
> Rarely, sure, but in the case where I do, it's probably an accident.  It
> would be nice to be notified of such accidents.

Possible, but the notification logic would have to be taught how to
tell relevant accidents (say, those in end-user scripts) from
irrelevant ones (perhaps those that come from tapset scripts).  That
particular rule may not be too hard to code, but if it's not just
right, we would spray users with too few or too many warnings.

> [...] However, I think that kind of optimization should occur
> *after* the script is validated.  [...]

Indeed, the optimization sub-pass runs after symbol but before type
checking.  The reason for this is that type checking will throw errors
if unresolved $target variables survive that far.  It is not clear how
to hack the type checker to permit these variables to pass, since
their "unknown" type could percolate to other downstream variables and
expressions, which themselves cause errors.

If this unresolved-$target check was moveable past the type-checking
phase somehow, I'd have no objection to moving the optimization phase
after type-checking.  That part is a one-liner change. :-)

> The normal optimization paradigm applies - there should be no
> _functional_ difference between optimized and unoptimized code.

True, but that dictum is normally applied to *legal* code.

> [...] It's very possible that someone with embedded-C could read
> data from 'global_b' - perhaps to use custom logging routines or
> something. [...]

But actually this is one of the reasons that embedded-C code is *not*
supposed to touch any such variables.  They should be, as far as
possible, pure functions of their input parameters, and not interfere
with any other systemtap runtime data.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature