This is the mail archive of the gcc-patches@gcc.gnu.org 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).


Hi, Richard,

Sorry for the late response due to company projects.
The followings are my discovery and modifications.


On 10/6/13 5:57 PM, Richard Sandiford wrote:
> 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?
> 

There is a statement in the try_split() in gcc/emit-rtl.c:

3458|   /* We're not good at redistributing frame information.  */
3459|   if (RTX_FRAME_RELATED_P (trial))
3460|     return trial;

You are correct, this is the statement that prevent the
instruction from splitting and then caused ICE in my porting.


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

Thanks for pointing out a direction.

I follow your suggestion to split large constant moves in the
movsi expander, using another predicate "nds32_move_operand"
to prevent large constant from being matched by define_insn:

+(define_insn "*mov<mode>"
+  [(set (match_operand:QIHISI 0 "nonimmediate_operand" "...")
+        (match_operand:QIHISI 1 "nds32_move_operand"   "..."))]
+ ...

+(define_predicate "nds32_move_operand"
+  (and (match_operand 0 "general_operand")
+       (not (match_code "high,const,symbol_ref,label_ref")))
+{
+  /* If the constant op does NOT satisfy Is20 nor Ihig,
+     we can not perform move behavior with single instruction.  */
+  if (CONST_INT_P (op)
+      && !satisfies_constraint_Is20 (op)
+      && !satisfies_constraint_Ihig (op))
+    return false;
+
+  return true;
+})

Now the case 16 and case 17 can be removed from output template
of the define_insn.  Thank you very much!


> Thanks,
> Richard
> 

A revised-3 patch for nds32.md is attached.
Thanks for the comments! :)

Best regards,
jasonwucj



Attachment: 2-nds32-backend-md-part2.v3.revised-3.patch
Description: Text document


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