This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: optimization


Frank Ch. Eigler wrote:
> I just committed some work toward PR 2060.  It's a new optimization
> sub-pass that runs during the elaboration phase, and aims to eliminate
> useless functions, assignments, expressions, variables.  "-u" disables
> it; "-v" tells you what it removed.
> 
> 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.

Really though, I have little hesitation about removing dead code -
that's perfectly valid.  However, I think that kind of optimization
should occur *after* the script is validated.  Looking in your test
script, things like 'b <<< "hello"' should throw an error, regardless of
whether you think 'b' is ever used.

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

Also note, in the presense of embedded-C, you need to be careful about
which global variables are considered used.  It's very possible that
someone with embedded-C could read data from 'global_b' - perhaps to use
custom logging routines or something.

> On the other hand, tapset code that aggressively defines lots of local
> variables from $target ones will see a drastic effect on debuginfo
> fault tolerance, and quite possibly performance.

I do understand the motivation here.  In this scenario, is there a case
where 'code elision' is necessary before the type-checking?  Or can this
be special-cased somehow?


Josh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]