On 2013/10/6 05:57 PM, Richard Sandiford wrote: >> > But case 16 is different. >> > This case is only produced at prologue/epilogue phase, using a temporary >> > register $r15 to hold a large constant for adjusting stack pointer. >> > Since prologue/epilogue is after split1/split2 phase, we can only >> > output "sethi" + "ori" directly. >> > (The "addi" instruction with $r15 is a 32-bit instruction.) > But this code is in the output template of the define_insn. That code > is only executed during final, after all passes have been run. If the > template returns "#", final will split the instruction itself, which is > possible even at that late stage. "#" doesn't have any effect on the > passes themselves. > > (FWIW, there's also a split3 pass that runs after prologue/epilogue > generation but before sched2.) > > However, ISTR there is/was a rule that prologue instructions shouldn't > be split, since they'd lose their RTX_FRAME_RELATED_P bit or something. > Maybe you hit an ICE because of that? > > Another way to handle this would be to have the movsi expander split > large constant moves. When can_create_pseudo_p (), the intermediate > results can be stored in new registers, otherwise they should reuse > operands[0]. Two advantages to doing it that way are that high parts > can be shared before RA, and that calls to emit_move_insn from the > prologue code will split the move automatically. I think many ports > do it that way (including MIPS FWIW).
FWIW, most ports usually just handle such "large adjustment" cases in the prologue/epilogue code manually; either multiple SP-adjustments, or use of a temp register (better control of RTX_FRAME_RELATED_P anyways). You might be able to get it to work, but trying to rely on the splitter does not seem like best practice... Chung-Lin
