The backends which support rotl now match for or(shl,shr) patterns.

They are considered low level operations now which just allocate/free a
block of memory on the stack. There is no highlevel typeinformation
attached anymore or support for heap allocation. Frontends/liboo should
provide their custom highlevel nodes if they need these features.

the templates are now friendlier for usage outside of libfirm

Templates are put in separate files now, making the main script more
generic in nature

They weren't used in a sensible way and their semantic for
non-arithmetic ops was unclear.
Also implicitely fixes a bunch of bugs where these where set but no op_index
was set at the same time.

oparity_unary, oparity_binary require opindex to be set, which wasn't
always the case.
Also people seem to expect certain semantics from unops/binops, like
being arithmetic operations. So we shouldn't automatically set
oparity_XXX.

Set magic parameters according to
http://stackoverflow.com/questions/1711631/how-do-i-improve-the-performance-of-sqlite.

Just state the copyright and the project the files belong to. You can
then find the COPYING file for the whole project.

So all files in libFirm do this consistently

It is the job of the frontend to keep loops.
These hacks here only worked for some, but not all cases.
In particular a more clever SSA-construction algorithm might not place redundant PhiMs, which would render memory before memory-less loops unkept.

get_irn_op_() checks the same.

This means floatingpoint calculation in a firm graph must be performed
in the mode specified (and may not be performed in a wider mode as
before).

Still broken for anything except int f(void) { return 0; } though...

Get away from the strange set_default_XXX_op style and instead let the
code modules register their node ops directly.