On fold_indirect_ref

[Richard Guenther]

Roger Sayle wrote:
> On Sun, 15 May 2005, Richard Guenther wrote:
> 
>>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.
> 
> 
> Exactly which optimization do we miss by changing:
> 
>       /* *&p => p */
> -     if (lang_hooks.types_compatible_p (type, optype))
> +     if (type == optype)
>         return op;

I don't know - maybe stripping sign casts.  But if we use equality
comparison here we can as well use STRIP_TYPE_NOPS instead of
STRIP_NOPS - but the patch doing so caused some optimization regressions.

If we want to simplify fold_indirect_ref_1 this way and enforce
type before == type after I can prepare a patch to do so.  Meanwhile
a patch that survived some testing is attached for reference - it
does fix some type issues but leaves the fixing of the types to
fold_indirect_ref.  Note that similarly build_fold_indirect_ref is
used in many places that look like they do not deal with mismatched
types.

Thanks for the input,
Richard.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: p
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20050515/05105b08/attachment.ksh>