[RFC] Tightening up the type system

[Diego Novillo]

Over the last few days I have found various places in the optimizers
where binary expressions and assignments had operands of non-compatible
types.

For instance, out of the gimplifier we were getting an assignment like
'iftmp.256 = 0B', where iftmp.256 was 'some_type *' and 0B was
'void *'.

We would then fail to propagate iftmp.256 because its constant value is
of the wrong type (may_propagate_copy would reject it).  This was caused
by tree_ssa_useless_type_conversion_1 stripping a (void *) from the
original FE trees.

In other cases we were generating boolean 'true'/'false' constants when
we really needed to be generating integer values (because of ABI
requirements).

So, as an experiment I added the attached patch to the statement
verifier.  Needless to say, we ICE almost immediately.  I first had to
exclude all the shift operators (tree.def states that the types may be
different).  But now I am getting a failure building libgcov.o on this
assignment

result = D.4720 + &__gcov_var.buffer[0];

(gdb) ptu t.exp.operands[0].common.type
const gcov_unsigned_t *
(gdb) ptu t.exp.operands[1].common.type
gcov_unsigned_t *

lang_hook.compatible_types_p is rejecting those two types because of the
const qualifier.

My question to the FE folks is: what are the right semantics for
checking MODIFY_EXPR?  Is compatible_types_p too strict?  Should we have
had a cast operation in the above assignment?

Not having the right types is increasingly getting in the way of the
optimizers because we use compatible_types_p quite often to validate
propagation opportunities.

In fact, I would like to get to the point where we can simply call
'gcc_assert (lang_hook.compatible_types_p (dest, orig))' when doing
propagation.  Ideally, all the necessary type conversions should be
exposed in the IL.


Thanks.  Diego.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 00
Type: text/x-patch
Size: 1712 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040928/0e238933/attachment.bin>