fix mem+32760 ICE on powerpc - provide/use predicates weaker than mode_dependent_address_p
David Edelsohn
dje.gcc@gmail.com
Fri May 4 18:42:00 GMT 2012
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
More information about the Gcc-patches
mailing list