This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/6] Andes nds32: machine description of nds32 porting (2).

2013/10/6 Chung-Lin Tang <>:
> On 2013/10/6 下午 06:33, Richard Sandiford wrote:
>> Chung-Lin Tang <> 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,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]