On Sun, 2006-08-13 at 10:53 -0700, Mark Mitchell wrote:
> (In my opinion, it doesn't really matter if MODIFY_EXPR is treated as
> doing an implicit conversion; the important thing is that the set of
> places where implicit conversions are performed be both limited and
> documented. If we save tons of TREE nodes by saying that MODIFY_EXPR is
> defined to do an implicit conversion, as if the right-hand side had a
> NOP_EXPR to convert it to the type of the left-hand side, then that
> might be a perfectly valid memory optimization on TREE.)
I don't think we save a ton, or even a half-ton. However, we do save
some memory, but more importantly by eliminating the pointless
casts we can often end up generating better code as many of our
optimizers are pretty weak when presented with NOP_EXPRs in the
IL.
There's also an outstanding issue with lots of silly typecasting
generating some really poor code for MIPS targets as measured by
some industry standard benchmarks. Some of these issues are poor
type selection by IVopts, others are gimple's requirement that
array indices be signed ints (unsigned int, signed shorts, etc
are forced into signed in types). Contact Nick C. for details
as he's most familiar with the code in question.
My point is that while it may seem nice and clean to have all the
type conversions be 100% explicit, but in practice it does cause
some problems.
Thus the existence of some implicit type conversions. IIRC the
places where these occur or occurred at one time or we pondered
allowing are:
1. MODIFY_EXPRs where the RHS can be implicitly converted to the
type of the LHS and the types do not vary in size/mode or
signedness. DOM probably makes more use of this than any
pass.
2. I think we sometimes implicitly convert COMPONENT_REF expressions.
ie, the field we're accessing has some type X, but we want a result
in some other type Y. Under certain circumstances we may access
the field in type Y. I believe this occurs during gimplification.
3. We may be allowing some implicit type conversions for function
arguments, particularly pointers.
I think the biggest problem with writing consistency checking for types
is that conversion of type X to type Y might be implicitly allowed, but
conversion of type Y to type X might not. This asymmetry can occur
for function pointers.
Jeff
