RE: optimization

RE: optimization

[Stone, Joshua I]

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

Re: optimization

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

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 #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: optimization

[James Dickens]

On 1/24/06, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
> 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.
>
Hi

perhaps -O  would be better since it would then be the same as  gcc uses.

James dickens
uadmin.blogspot.com



> Plain script code should not be affected (since one only rarely puts
> in a deliberately unused side-effect-free expression).  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.
>
> Please let me know of any problems you notice.
>
> - FChE
>

optimization

[Frank Ch. Eigler]

Hi -

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).  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.

Please let me know of any problems you notice.

- FChE