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-Lin Tang <cltang at codesourcery dot com>
- To: Chung-Ju Wu <jasonwucj at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, <rdsandiford at googlemail dot com>
- Date: Sun, 6 Oct 2013 19:27:34 +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>
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:
>>>>> 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. 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.
Okay, I sort of missed the context.
> 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" ;)