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

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

2013/10/6 Richard Sandiford <rdsandiford@googlemail.com>:
> Chung-Ju Wu <jasonwucj@gmail.com> writes:
>> On 10/2/13 1:31 AM, Richard Sandiford wrote:
>>> Chung-Ju Wu <jasonwucj@gmail.com> writes:
>>>> +      /* Use $r15, if the value is NOT in the range of Is20,
>>>> +         we must output "sethi + ori" directly since
>>>> +         we may already passed the split stage.  */
>>>> +      return "sethi\t%0, hi20(%1)\;ori\t%0, %0, lo12(%1)";
>>>> +    case 17:
>>>> +      return "#";
>>>
>>> I don't really understand the comment for case 16.  Returning "#"
>>> (like for case 17) forces a split even at the output stage.
>>>
>>> In this case it might not be worth forcing a split though, so I don't
>>> see any need to change the code.  I think the comment should be changed
>>> to give a different reason though.
>>>
>>
>> Sorry for the misleading comment.
>>
>> For case 17, we were trying to split large constant into two individual
>> rtx patterns into "sethi" + "addi" so that we can have chance to match
>> "addi" pattern with 16-bit instruction.
>>
>> 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?
>

Ah... yes, you are right.  In the nds32_force_addi_stack_int(),
I move a large constant to a temp register for stack pointer adjustment:

+      /* $r15 is going to be temporary register to hold the value.  */
+      tmp_reg = gen_rtx_REG (SImode, TA_REGNUM);
+
+      /* Create one more instruction to move value
+         into the temporary register.  */
+      value_move_insn = emit_move_insn (tmp_reg, GEN_INT (full_value));
+
+      /* At prologue, we need to tell GCC that this is frame related insn,
+         so that we can consider this instruction to output debug information.
+         If full_value is NEGATIVE, it means this function
+         is invoked by expand_prologue.  */
+      if (full_value < 0)
+        RTX_FRAME_RELATED_P (value_move_insn) = 1;
+
+      /* Create new 'add' rtx.  */
+      sp_adjust_insn = gen_addsi3 (stack_pointer_rtx,
+                                   stack_pointer_rtx,
+                                   tmp_reg);
+      /* Emit rtx into insn list and receive its transformed insn rtx.  */
+      sp_adjust_insn = emit_insn (sp_adjust_insn);
+
+      /* At prologue, we need to tell GCC that this is frame related insn,
+         so that we can consider this instruction to output debug information.
+         If full_value is NEGATIVE, it means this function
+         is invoked by expand_prologue.  */
+      if (full_value < 0)
+        RTX_FRAME_RELATED_P (sp_adjust_insn) = 1;

If there is a rule to avoid spliting instructions with RTX_FRAME_RELATED_P,
I think it is the case why I hit an ICE of unrecognized insn for
'value_move_insn'.

It seems that my comment to case 16 is incorrect.
Thanks for clarifying it.

> 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).
>

Do you mean that I should split large constant by myself in movsi
(or starting from movsi) for both case 16 and case 17?

Thanks for the suggestion.  I'll try to implement it. :)


Best regards,
jasonwucj