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.
