"Qian, Jianhua" <qia...@cn.fujitsu.com> writes:
> Hi Richard
>
>> -----Original Message-----
>> From: Richard Sandiford <richard.sandif...@arm.com>
>> Sent: Friday, January 8, 2021 7:04 PM
>> To: Qian, Jianhua/钱 建华 <qia...@cn.fujitsu.com>
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH v2] aarch64: Add cpu cost tables for A64FX
>>
>> Qian Jianhua <qia...@cn.fujitsu.com> writes:
>> > This patch add cost tables for A64FX.
>> >
>> > ChangeLog:
>> > 2021-01-08 Qian jianhua <qia...@cn.fujitsu.com>
>> >
>> > gcc/
>> > * config/aarch64/aarch64-cost-tables.h (a64fx_extra_costs): New.
>> > * config/aarch64/aarch64.c (a64fx_addrcost_table): New.
>> > (a64fx_regmove_cost, a64fx_vector_cost): New.
>> > (a64fx_tunings): Use the new added cost tables.
>>
>> OK for trunk, thanks. The v1 patch is OK for branches that support
>> -mcpu=a64fx.
>>
>> Would you like commit access, so that you can commit it yourself?
>> If so, please fill out the form mentioned at the beginning of
>> https://gcc.gnu.org/gitwrite.html listing me as sponsor.
>>
> It‘s my pleasure. I've applied it.
Great!
> Thank you so much.
>
> I don't quite know the process of gcc source committing.
> If I have the commit access, how will process be different?
The patch submission process is pretty much the same: patches need
to be sent to the list and most patches need to be approved by a
reviewer or maintainer. The main differences are:
- If a patch is “obviously correct”, you can apply it without going
through the approval process. (Please still send the patch to the
list though.)
- Once a patch has been approved, you can commit the patch yourself,
rather than rely on someone else to do it for you. The main benefits
of this are:
- You can commit from the tree that you actually tested.
- You can deal with any merge conflicts caused by other people's
patches without having to go through another review cycle. (Most
merge conflict resolutions are “obvious” and so don't need approval.)
- A typical workflow is to test a patch on trunk, post it for review,
and ask for approval to apply the patch to both trunk and whichever
branches are appropriate. If the patch is approved, you can later
test the patch on the approved branches (at your own pace) and
apply it if the tests pass.
In terms of the mechanics of committing, just “git push” should work.
The server hooks will check for things like a well-formed changelog.
https://gcc.gnu.org/gitwrite.html has more info about the process
in general. Quoting from that page, the next step is:
Check out a tree using the instructions below and add yourself to the
MAINTAINERS file. Note: Your first and last names must be exactly the
same between your account on gcc.gnu.org and the MAINTAINERS file.
Place your name in the correct section following the conventions
specified in the file (e.g. "Write After Approval" is "last name
alphabetical order").
Then produce a diff to that file and circulate it to the gcc-patches
list, whilst also checking in your change to test write access
(approval from the mailing list is not needed in this one case). For
all other changes, please be sure to follow the write access policies
below.
> And which branch, which range(aarch64?) could I commit patches to?
This patch should go to master. The v1 patch should go to
releases/gcc-10 and releases/gcc-9.
You might need to remove some lines from the cost tables when
backporting to gcc-10 and gcc-9 (I haven't checked). If so, that kind
of change counts as “obviously correct” and so doesn't need approval.
Hope this helps. Please let me know if you have any questions.
Thanks,
Richard
