GitLab

You can still attach NoMem if no memory input is present.
This makes it more consistent with the Call node and fixes failing
get_ASM_mem in case of no memory input.

This commit removes the strange differentiation between
ir_visibility_external and ir_visibility_default. We now only have
ir_visibility_external for all symbols visible across compilation units.
You may or may not attach graphs/initializers to them.

(otherwise CSE merges temporary Phi nodes without inputs)

It was a member of ir_prog before but not correctly handled.

The first block in a new ir_graph is not an immature block anymore. The
end block is matured in irg_finalize_cons() now (since maturing blocks
twice doesn't hurt this shouldn't break existing code).

The opcode list was a member of irprog before which wasn't really
handled consistently. Also make sure opcodes are properly freed at
ir_finish().

unknown_type, code_type, none_type, unknown_entity reference are hold in
the irprog now. This makes handling more consistent since now all types
and entities are equally part of irprog.

This should fix all known bugs, make the code easier to read and more
robust.

The main change here is splitting new_ir_mode into new_int_mode,
new_reference_mode and new_float_mode. You can now specify
mantissa+exponent size in new_float_mode. This also changes:

- x86 80bit-FP mode is NOT a ieee754 don't put "ieee754" into functions
  names that can also handle x86 80bit fps
- Move ieee_descriptor_t from tarval module into ir_mode struct
  (and rename to float_descriptor_t)
- Introduce mode_Q which represents binary128 from ieee754
- You can ask float modes for mantissa/exponent sizes now
- Fix endianess when emitting big float values in begnuas
- A bunch of long double fixes in ia32: the mode there has 10bytes
  (80bit) but the variables typically are 12 or 16 byte big
- This fixes some problems of sparc binary128 handling

There were no users and no tarval support anyway.

Use a special kind of entity on the frame type instead of a value_type
struct inside a method type. This makes replacement of function types
slightly easier (it's still a complex operation though) and handling in
the backend a bit more consistent since it's more or less a normal stack
access (with special offsets).

[r28375]

[r28340]

[r28220]

[r28219]

[r28218]

[r28217]

[r28216]

you can specify in the spec now for which nodes no standard import/export code is generated; fix bug with Proj nodes block

[r28215]

[r28210]

[r28127]

[r28062]

[r28061]

[r28037]

[r28030]

[r27467]