On fold_indirect_ref

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

So, fold_indirect_ref is used in places where we explicitly deal with
lvalues, like in the vararg optimizations in builtins.c and in
gimplfiy_expr.  It is also used to perform optimizations that temp1.C
checks - which originates from gimplify_modify_expr_rhs where in turn
we know we're dealing with a rhs.  fold_indirect_ref is _not_
unconditionally called for INDIRECT_REF nodes in fold_unary - for sure
the one who added fold_indirect_ref knows why :)

Currently fold_indirect_ref possibly changes the type of the results,
f.i. by stripping casts, making using it on LHS dangerous.  Also
using it on LHS makes it impossible to restore type-safeness by
fold_converting to the original type, as a LHS does not like to be
(char)c for c of type const char.  One would have to use a
VIEW_CONVERT_EXPR here, but this in turn confuses optimizers in
case we know we're dealing with a RHS.

What can be done about this issues?  First, we can use VIEW_CONVERT_EXPR
unconditionally in fold_indirect_ref and only break some optimizations
(like temp1.C).  Second, we can declare fold_indirect_ref being unsafe
about types and deal with this in its callers where we possibly know
about if we're dealing with lvalues or rvalues, using either NOP_EXPRs
or VIEW_CONVERT_EXPRs as appropriate.  We could ease this with providing
wrappers around fold_indirect_ref (or a flag) - but checking if we're
(possibly) dealing with a lhs is not possible, so uses may remain
unsafe.

I'll happily go any way you direct me, but please do so, because I'm stuck.

Thanks,
Richard.