[GiNaC-list] 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 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). 

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