Hi Richard > >> > 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. >
Thanks for detailed information. I understood. > 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"). > I've already added myself to MAINTAINERS file. > 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. > I will commit this patch to master tomorrow. Then make some changes, and push to gcc-10 and gcc-9. > Hope this helps. Please let me know if you have any questions. > Thanks again. Regards, Qian > Thanks, > Richard >
