Hendrik Greving wrote: > Yes :) I am asking about 3.2.3 but I think the reload concepts should > be about the same. From what I can tell, most of the code I looked at > was almost identical to GCC 4.7.3.
Yes, but it was completely rewritten for GCC 4.8 :-) See e.g. the following email (and the thread leading up to it and following it) for an extensive discussion of why we did this in the past, and why we're now no longer doing it: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01421.html > Note that we are setting the mode of the memory to the bigger > (paradoxical) part of the subreg. How can we just set the mode, does > somebody make sure this memory is actually allocated? I noticed even > new GCC does that. Is this correct? The code used to verify that this was OK by: - proving that the updated memory address was naturally aligned for the larger access size, which means that the memory access would be guaranteed to not trap; of course, the particular values of the extra bytes read are undefined -- but that is OK according to the semantics of a paradoxical subreg. - for the special case of accessing a stack (spill) slot that is assigned by the compiler in the first place, making sure that the stack slot is big enough to allow accesses in larger modes if such paradoxical subregs exist in the code. > Going back where we call find_reloads_subreg_address: > > else if (regno >= FIRST_PSEUDO_REGISTER > #ifdef LOAD_EXTEND_OP > && (GET_MODE_SIZE (GET_MODE (x)) > <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))) > #endif > && (reg_equiv_address[regno] != 0 > || (reg_equiv_mem[regno] != 0 > && (! strict_memory_address_p (GET_MODE (x), > XEXP (reg_equiv_mem[regno], 0)) > || ! offsettable_memref_p (reg_equiv_mem[regno]) > || num_not_at_initial_offset)))) > x = find_reloads_subreg_address (x, 1, opnum, type, ind_levels, > insn); > > I have 2 questions here. Why does the fact whether or whether we don't > have load extended ops matter when widening (or narrowing) the reload > location (find_reloads_subreg_address)? Same question for > req_equiv_address, why does this matter whether or not we end up > widening/narrowing the memory location? I agree that the particular condition cited above was not really very precise; see the mail linked to above for discussion in detail. In the current (4.8) code this is much simplified :-) > Generally speaking, does it look fine to you that we end up > spilling/reloading mem:HI on the one hand, but mem:SI on the other? The way we used to do it was correct (in most cases, including your test case), but somewhat confusing and proved not particularly useful in the end, so we changed it. Current compilers will never transform paradoxical subregs to accessing excess bytes in memory any more. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
