[GiNaC-list] GiNaC is not a compiler (Was: Term ordering and compiling C++ code)

[Alexei Sheplyakov]

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 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.

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). 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ginac2llvm.tar.bz2
Type: application/octet-stream
Size: 353182 bytes
Desc: not available
URL: <http://www.cebix.net/pipermail/ginac-list/attachments/20100524/4a986093/attachment-0001.dll>