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

[Chung-Ju Wu <jasonwucj at gmail dot com>]

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