This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/6] Andes nds32: machine description of nds32 porting (1).
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Chung-Ju Wu <jasonwucj at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 08 Oct 2013 20:40:38 +0100
- Subject: Re: [PATCH 2/6] Andes nds32: machine description of nds32 porting (1).
- Authentication-results: sourceware.org; auth=none
- References: <CADj25HMFJUOHWC5ZvDOrJH+xkCoN8sxHXhD2vb36bM95irWEdg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1307092307170 dot 29921 at digraph dot polyomino dot org dot uk> <51EFF75C dot 2070705 at gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1307241606370 dot 31023 at digraph dot polyomino dot org dot uk> <51F0F15E dot 1050606 at gmail dot com> <522CA211 dot 60200 at gmail dot com> <8761u4losy dot fsf at talisman dot default> <5245CAB9 dot 8050400 at gmail dot com> <87siwnlvi5 dot fsf at talisman dot default> <52505830 dot 9080800 at gmail dot com> <87pprispu3 dot fsf at talisman dot default> <52541E04 dot 3010303 at gmail dot com>
Chung-Ju Wu <jasonwucj@gmail.com> writes:
> On 10/6/13 5:36 PM, Richard Sandiford wrote:
>> Thanks for the updates.
>>
>> Chung-Ju Wu <jasonwucj@gmail.com> writes:
>>>
>>> Now we remove all "use"s and "clobber"s from parallel rtx and
>>> use predicate function to check stack push/pop operation.
>>> Furthermore, once I remove unspec rtx as you suggested,
>>> I notice gcc is aware of the def-use dependency and it wouldn't
>>> perform unexpected register renaming. So I think it was my
>>> faulty design of placing unspec/use/clobber within parallel rtx.
>>
>> FWIW, it'd probably be better for nds32_valid_stack_push_pop to check
>> all the SETs in the PARALLEL, like nds32_valid_multiple_load_store does.
>> They could share a subroutine that checks for conesecutive loads and stores.
>> I.e. something like:
>>
>> static bool
>> nds32_valid_multiple_load_store_1 (rtx op, bool load_p, int start, int end)
>> {
>> ...
>> }
>>
>> bool
>> nds32_valid_multiple_load_store (rtx op, bool load_p)
>> {
>> return nds32_valid_multiple_load_store_1 (op, load_p, 0, XVECLEN (op, 0));
>> }
>>
>> bool
>> nds32_valid_multiple_push_pop (rtx op, bool load_p)
>> {
>> ...handle $lp, $gp and $fp cases, based on cframe->...
>> if (!nds32_valid_multiple_load_store_1 (op, load_p, i, count - 1))
>> return false;
>> ...check last element...
>> }
>>
>
> Now I follow your suggestion to implement a subroutine
> nds32_consecutive_registers_load_store_p().
> Both nds32_valid_multiple_load_store() and nds32_valid_stack_push_pop()
> can share this subroutine to check consecutive load/store behavior.
>
> A revised-3 patch for nds32.c is attached.
Looks good to me, thanks. FWIW, I was wondering if we could simplify things
by making the order of the SETs in the PARALLEL the same for push and pop,
but it's probably not much of a win.
Thanks,
Richard