Next: Error Reporting, Previous: Application Defined Types, Up: Expression Evaluator [Index]
Expression optimization may (well, it should) reduce the evaluation time and the storage and evaluation memory requirements. However, since the optimization logic is not fast when compared with the evaluation logic, optimizing expression is usually pointless for one time evaluations.
The expression evaluator can performed a few simple expression optimizations, such as constant subexpression elimination, identity (or neutral) element elimination for operations defining one (such as addition and multiplication), etc.
Most optimizations are generic, i.e. the optimizer does not have built-in knowledge of function and operator properties and is instead deriving the possible optimizations from the function and operator definitions.
See Optimizing Prefix Unary Operators.
See Optimizing Infix Binary Operators.
Expression can be optimized through the x1f4_line_expression and
x1f4_rule_expression functions.
See x1f4_line_expression.
See x1f4_rule_expression.
No side effects operators (X1f4_LEFT_XSET marked) and no application
indicated as having side effects (X1f4_KEEP_CALL marked) functions and
operators are optimized away.
See Operator And Function Flags.
The optimizer does not expect void functions to not have side effects,
hence attempts to optimize expression referring void functions not being
indicated as having side effects (X1f4_KEEP_CALL marked) should only be
considered as alternative to
raise(SIGSEGV);
Optimizing expressions is in effect partial evaluation and thus all the evaluation requirements and prerequisites apply for optimizing as well. There are no requirements made by the expression evaluator, but there may be some coming from the function, operator, type definitions, etc (e.g. if a function requires a special context available for execution, it will also require it for optimization).
Next: Error Reporting, Previous: Application Defined Types, Up: Expression Evaluator [Index]