This is achieved by the introduction of a TARGET_MAY_NARROW_ACCESS target
hook, which defaults to !mode_dependent_address_p and is redefined for
powerpc. The patch uses this hook directly instead of the former predicate in
a couple of places where this was the intent already, as well as new
"valid_access_mode_change_p" function to direct to one or the or the other
depending on provided original and destination modes.

This provides a better match for actual internal needs, allows to get rid of
the powerpc back-end twists (no need to lie in mode_dependent_address_p any
more) and cures the observed internal compiler error.

The patch was bootstrapped and regression testsed for mainline on both x86_64
and powerpc-linux. We (AdaCore) also have been using a gcc-4.5 minor variation
of it without problem for a couple of years on powerpc-aix.

OK to commit ?

        * target.def (TARGET_MAY_NARROW_ACCESS_TO): New hook.
        * doc/tm.texi[.in] (TARGET_MAY_NARROW_ACCESS_TO): Document.
        * targhooks.c (default_may_narrow_access_to): Default implementation.
        * targhooks.h (default_may_narrow_access_to): Declare.
        * config/rs6000/rs6000.c (rs6000_may_narrow_access_to): Specific
        implementation.
        (rs6000_mode_dependent_address): Stop lying for + const_int.
        (rs6000_offsettable_memref_p): Adjust comments accordingly.
        * expr.c (convert_move): Use may_narrow_access_to instead of
        mode_dependent_address_p where appropriate.
        * recog.c (offsettable_address_addr_space_p): Likewise.
        (valid_access_mode_change_p): New function.
        * recog.h (valid_access_mode_change_p): Declare.
        * simplify-rtx.c (simplify_subreg): Use it instead of
        mode_dependent_address_p where appropriate.

        testsuite/
        * gcc.dg/offsetmem.c: New test.

I cannot approve the common parts of the patch, but the rs6000 parts are okay.

The new comment in rs6000_mode_dependent_address adapted from the
original comment above the hook should mention VSX in addition to
Altivec for clarity.

Thanks, David

Reply via email to