Types need not be in their final form after the new_entity so there is no
need to have _d variants like we have with all the graph nodes. You can easily
use set_entity_dbg_info() after construction.

Entities need not be in their final form after the new_entity call, so
there is no need to have _d variants like we have with all the graph
nodes. You can easily use set_entity_dbg_info() after construction.

It is not usefull for optimization in most languages:
- In C/C++ you can't really change the value of enum constants as casting
  from/to integer has to produce the expected results.
- In Java (and other OO languages) enum members are objects so the
  libfirm enumeration type can't be used there anyway

This allows users - such as Special Instruction creation for
reconfigurable microarchitectures - to override the backend's
predicate.

Code using get_alias_relation is converted by calling get_type_for_mode at
the appropriate locations.

This is in preparation for optimizations involving CopyB, which needs this
additional flexibility.

The new code has less options and variants, if you call irg_verify()
verification is performed, regardless of DEBUG_libfirm, or NDEBUG being
set and regardless of firm verification setting switches. On the other
side no atomic dump and abort is performed anymore, the call has to do
this, though an irg_assert_verify() function has been added as a
convenience measure.
There has also been a complete rewrite of the actual checking performed.
The new code is simpler, should produce more consistent output and
can report more than one error.

also move copy_const_value from typerep/entity to irgmod.

This also fixes a bug where irout computation would claim that it
removed all tuples, but missed tuples just held by a keepalive edge.

We do not model them as a type anymore, but simply annotate
compound_member entities with a bit offset and bit size.

I don't really understand what it was supposed to do (because nodes
using/producing should be pretty much immovable anyway because of their
dependencies, so an additional pinning type appears unnecessary).
In practice there was no code differentiating between mem_pinned and exc_pinned.

- You can now construct the lookup table separately and perform the
  lowering selectively on irgs (instead of the whole program at once)
  while reusing the lookup table.
- Simplified API a bit.
- Remove i_mapper_RuntimeCall. All users are simpler by doing the
  transformations directly instead of filling in runtime_rt
  structures...

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

Nobody uses it currently, and it is a burden for everyone writing a new
pass.

Most aspects of the fp_model flag would need to be enforced by
constructing the firm graph in a certain way. Setting it as a flag won't
help. Apart from that nearly nothing of the stuff was implemented
anyway.

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

The builtin can be used to generate fast code for unsigned division by constant.

Code generation is supported for the IA32 and the SPARC backend.
Since our ARM backend currently has no Add with Carry instruction,
the builtin is currently not supported on Arm.
The same holds for the AMD64 backend, which does not support a division yet.

Now we have a simple optimization actually using DCA.

- Semantic was strange: shallow checking for pointers, deep checking for
  structs (because no real solution in case of cycles was implemented)
- Implementation was incomplete/buggy
- Nobody was using it anyway

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.