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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Chung-Lin Tang <cltang@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.

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.

Thanks,
Richard