[GiNaC-list] Term ordering and compiling C++ code
alexei.sheplyakov at gmail.com
Mon May 24 21:38:57 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 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.
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: 5970 bytes
Desc: not available
More information about the GiNaC-list