[Bug target/28896] -fstack-limit-symbol and m68k and non 68020

["baker at usgs dot gov" <gcc-bugzilla at gcc dot gnu dot org>]

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.