http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #16 from Larry Baker <baker at usgs dot gov> 2012-08-17 16:45:22 UTC --- Here are some notes about the patches I made. 1. An alternative to my m68k.md patch: - rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode); + rtx temp = can_create_pseudo_p() ? gen_reg_rtx (Pmode) : operands[0]; might be the approach taken by m68k_output_mi_thunk() in m68k.c: /* Pretend to be a post-reload pass while generating rtl. */ reload_completed = 1; : if (!TARGET_SEP_DATA) { /* Use the static chain register as a temporary (call-clobbered) GOT pointer for this function. We can use the static chain register because it isn't live on entry to the thunk. */ SET_REGNO (pic_offset_table_rtx, STATIC_CHAIN_REGNUM); emit_insn (gen_load_got (pic_offset_table_rtx)); } : /* Clean up the vars set above. */ reload_completed = 0; /* Restore the original PIC register. */ if (flag_pic) SET_REGNO (pic_offset_table_rtx, PIC_REG); This fools the compiler by pretending to run post-reload pass (reload_completed = 1). That might have been for the same reason I made the one-line patch above to m68k.md. I am not sure the approach taken in m68k_output_mi_thunk() would be correct in m68k_expand_prologue() in m68k.c: • The alternative code does not undo the effects of an instruction that sets crtl->uses_pic_offset_table while the temporary PIC offset table register is being used. That might cause an unnecessary load of the true PIC offset table register (emit_insn (gen_load_got (pic_offset_table_rtx)) at the end of m68k_expand_prologue()). • I do not know if the prerequisite holds that the static chain register is available in m68k_expand_prologue(). • I do not know if a pseudo register could be created in the stack check code but never be assigned to an actual register since the reload pass has already been run. I decided the patch I made to m68k.md was safe since it followed the intent of the existing conditional that decided whether or not to call gen_reg_rtx() and it did not try to use any registers designated for other purposes or not yet saved. All I did was move the code as-is from before to after the code that set up the PIC offset table register, and, only when that was required (!TARGET_SEP_DATA && crtl->uses_pic_offset_table). 2. From what I understand of the GCC Internal Manual, the define_expand TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4 is ignored by the time those expansions are inserted into the RTL list (by the define_expand "prologue" pattern). In fact, my implementation of a conditional trap pattern for the other architectures would not have been invoked if it had been otherwise. The correct insn's for conditional_traps will be selected when the define_insn patterns are matched and expanded. I concluded it is correct to remove the TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4 in m68k.md.