This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 2/6] Andes nds32: machine description of nds32 porting (2).
- From: Chung-Ju Wu <jasonwucj at gmail dot com>
- To: Chung-Lin Tang <cltang at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, rdsandiford at googlemail dot com
- Date: Sun, 6 Oct 2013 21:39:02 +0800
- Subject: Re: [PATCH 2/6] Andes nds32: machine description of nds32 porting (2).
- Authentication-results: sourceware.org; auth=none
- References: <CADj25HOO04tn85ZfL2adeHUo8EL7mGwFf8yB4CadofGCNVszVQ at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1307092324060 dot 29921 at digraph dot polyomino dot org dot uk> <51EFF7CA dot 6050601 at gmail dot com> <51F0F2F5 dot 6040905 at gmail dot com> <522CA258 dot 2010403 at gmail dot com> <87six7k4x5 dot fsf at talisman dot default> <5245CAF2 dot 2020106 at gmail dot com> <87had0lwyg dot fsf at talisman dot default> <525058A5 dot 4020504 at gmail dot com> <87li26sowi dot fsf at talisman dot default> <52513B25 dot 3070507 at codesourcery dot com> <87d2nisn84 dot fsf at talisman dot default> <52514926 dot 7060608 at codesourcery dot com>
2013/10/6 Chung-Lin Tang <email@example.com>:
> On 2013/10/6 下午 06:33, Richard Sandiford wrote:
>> Chung-Lin Tang <firstname.lastname@example.org> 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. 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" ;)
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. :)