[GiNaC-list] GiNaC is not a compiler (Was: Term ordering and compiling C++ code)
alexei.sheplyakov at gmail.com
Mon May 24 21:27:52 CEST 2010
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 algorithms).
For example, GiNaC tries to make expression tree as flat as possible
(to save memory and make collecting similar terms more efficient).
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.
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
argument to llc (the default register allocator is way too memory hungry).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 353182 bytes
Desc: not available
More information about the GiNaC-list