2013/10/6 Chung-Lin Tang <clt...@codesourcery.com>: > 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: >>>> 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. > >> 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 >
Hi, Chung-Lin, Thanks for the hint. ^_^ I will follow Richard and your suggestion to split large constant via movsi manually. So that it will be automatically split whenever emit_move_insn() is used. :) Best regards, jasonwucj
