Hello, On Thu, May 13, 2010 at 10:31:48AM -0400, jros wrote:
Probably allowing/disallowing some kind automatic simplifications (so that subexpression sharing expected value increases) can probably help to obtain improved results.
I wonder what do the developers think about this.
GiNaC is not a compiler. It's data structures and algorithms are not suitable for finding common subexpressions (and other optimization tasks). For example, GiNaC tries to make expression tree as flat as possible. Thus, (a + b) + c is automatically transformed into a + b + c (which is probably not what you want for finding common subexpressions). However, it saves memory and makes collecting similar terms more efficient. The bottom line is: use the right tool. If you need a compiler, use a compiler, not a symbolic computation engine. Best regards, Alexei P.S. Attached is the code which I use for converting a GiNaC expression into LLVM (http://llvm.org) intermediate representation. It reads the expression, converts it into LLVM IR, applies some common optimizations, and saves the output as a LLVM (pseudo) asm. Later one can apply further optimizations (using the `opt' utility), and compile into a native code (using llc). To compile any `intersting' expression (> 10^5 terms), pass the -regalloc=local argument to llc (the default register allocator is way too memory hungry).