Optimize precedence handling
commit56343ee766052316732a73d27ff43ae3805d63a1
authorPetr Tesarik <petr@tesarici.cz>
Tue, 16 Oct 2012 04:04:54 +0000 (16 06:04 +0200)
committerPetr Tesarik <petr@tesarici.cz>
Tue, 16 Oct 2012 04:04:54 +0000 (16 06:04 +0200)
tree8f0bcfd9971ca83eb61c55efa146553193d2ea48
parent6ca6681b2afdc062d52baa1379c67228bf437f8f
Optimize precedence handling

1. Add "holes" in the precedence values

The actual precedence value doesn't matter, only their relations do.
So, I can leave some space for possible future enhancements. The
largest hole is at the beginning, because additional low-precedence
operators are more likely to be added.

2. Use a table to get the precedence value of an operator

Since all operators come from a trusted source (the expression parser
itself), this allows to optimize away handling of an unknown operator
without causing a compiler warning.

3. Mark precedence() as inline

This function is trivial enough to be inlined now. Gcc would inline it
even if it wasn't marked as such, but let's be nice to other compilers.

4. Pass the minimum precedence itself to reduce_stack()

As a result, the value of precedence(ABO_RPAREN) is known at compile
time and can be optimized to a constant.
libhed/expr.c