On Sun, May 6, 2012 at 11:41 AM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > x32 uses a mixture of MEM address modes for the same address space. > Some MEMs have SImode addresses, some have DImode. This means that > the currently common idiom: > > targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem)) > > isn't trustworthy. We have to use the mode of the address if it has one, > and only fall back on the above for VOIDmode (CONST_INT) addresses. > > We actually already have two (identical) functions to calculate > such a mode. The patch below puts the function in a more general place > and uses it instead of the above for rtl-level stuff. > > I'm not sure whether what x32 is doing is a good thing, but I like the > patch anyway because (a) it removes a duplicated function and (b) it at > least abstracts the concept away. > > Bootstrapped & regression-tested on x86_64-linux-gnu. Also tested to > make sure that there were no differences for cc1 .ii files for MIPS > n32, o32 and n64. (I used MIPS to get LO_SUM coverage.) OK to install? > > Richard > > > gcc/ > PR middle-end/53249 > * dwarf2out.h (get_address_mode): Move declaration to... > * rtl.h: ...here. > * dwarf2out.c (get_address_mode): Move definition to... > * rtlanal.c: ...here. > * var-tracking.c (get_address_mode): Delete. > * combine.c (find_split_point): Use get_address_mode instead of > targetm.addr_space.address_mode. > * cselib.c (cselib_record_sets): Likewise. > * dse.c (canon_address, record_store): Likewise. > * emit-rtl.c (adjust_address_1, offset_address): Likewise. > * expr.c (move_by_pieces, emit_block_move_via_loop, store_by_pieces) > (store_by_pieces_1, expand_assignment, store_expr, store_constructor) > (expand_expr_real_1): Likewise. > * ifcvt.c (noce_try_cmove_arith): Likewise. > * optabs.c (maybe_legitimize_operand_same_code): Likewise. > * reload.c (find_reloads): Likewise. > * sched-deps.c (sched_analyze_1, sched_analyze_2): Likewise. > * sel-sched-dump.c (debug_mem_addr_value): Likewise. >
X32 results look good: http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00704.html Thanks. -- H.J.
