dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]GenDiscard and GenValue


From: Rhys Weatherley
Subject: [DotGNU]GenDiscard and GenValue
Date: Sat, 19 Oct 2002 18:34:43 +1000

James Michael DuPont wrote:

> Gen and Discard, what does that do? please expand on that.

They are node operations within the codegen directory.  They refer
to the slightly different way in which nodes must be compiled in
different circumstances.  e.g. the assignment in the following:

    x = y + 1;
    if((x = y + 1) > 0) ...

The first, being a statement, is generated using GenDiscard, because
the final value of the expression is "discarded".  The second, being
an expression, is generated using GenValue, because the value is
still needed for the ">" test.  GenDiscard is fairly simple, whereas
GenValue is more complex because it must save the value.  The other
node operations are:

GenThen

    Evaluate the expression and jump to a label if true.

GenElse

    Evaluate the expression and jump to a label if false.

EvalConst

    Evaluate the constant value of the node, if possible.

Prepare

    Prepare a destination to receive a value.  This does nothing
    for a local, but needs to push the object reference for a field.
    It is typically used for assignment.

GetAndPrepare

    Get the value in a location, and also prepare for a later store.
    This is typically used for "+=", "-=", "++", etc.  GetAndPrepare
    may optionally leave the previous value on the stack (e.g. "x++").

Store

    Store the value into a prepared location, and optionally leave
    the final value on the stack (e.g. "++x").

Each of these cases can be optimized more effectively if they are
split out.

Similar situations apply with register machine code.  e.g. if the
code generator knows that the initial value of "x++" is not needed
by a higher-level expression, it doesn't need to save it away in
a register.

There are other ways to handle this.  e.g. always do GenValue and
remove redundant operations with peephole optimization.  Doing so
moves the complexity out of the node operations into the peephole
phase.  Treecc doesn't have much support for rule-based optimization
at present, which makes writing peephole optimizers a manual,
and error-prone task.  I hope to rectify this some day, but need
to do a bit more research first.

Cheers,

Rhys.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]