On 2013/10/6 下午 06:33, Richard Sandiford wrote: > Chung-Lin Tang <clt...@codesourcery.com> writes: >> 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... > > To be clear, I wasn't talking about relying on the splitter in the > define_split sense. I was saying that the move expanders could > split large constants.
Okay, I sort of missed the context. > MIPS prologue code does use emit_move_insn to move large constants, > which automatically produces a split form from the outset. I don't > really agree that it's bad practice. I think that's mostly the same as what I meant by "manually"; it seems that there's lots of MIPS backend machinery starting from mips_legitimize_move(), so it's not really "automatic" ;) Chung-Lin
