Changed codegen to work with Mach-O. Though the runtime partrequires some CMake (which I lack) expertise to move more progress
Fixed semantics of some obscure driver options
Helped fixing metadata section usage for featuress like-fexperimental-sanitize-metadata= and-fpseudo-probe-for-profiling
MC
Removed many obsoleted workarounds from the integratedassembler
Fixed placement of function entry comments
Re-architectured a substantial part of the integrated assembler thatis used by RISC-V linker relaxation, fixing some longstanding bugs. SeeThedark side of RISC-V linker relaxation for detail.
clangDriver
Made output files more meaningful when combining compilation andlinking phases for certain options: -gsplit-dwarf,-ftime-trace, --coverage. See Compiler output filesfor detail
made target-specific option report an error when used with adifferent target. Previously Clang merely issued warnings likewarning: argument unused during compilation: '-msse' [-Wunused-command-line-argument]
-fdebug-prefix-map=: made the last win when multipleprefixes match
At the present, LLVM uses a self-hosted Phabricator for code review.I have accepted or rejected 381 Phabricator Differentials (patches)during the 181 days. (I will mention how I get this number later.) Ihope that the number is fabulous, considering so many other tasks I haveto do at work for bread and butter. Here is an incomplete list:
RISC-V patches related to assembler, linker, and psABI
LLVMSupport patches
Mips and LoongArch patches
In June 2023, a fulldisk issue occurred with the server, which led to the rejection ofnew patch uploads. To address this problem, I expanded the database disksize from 500GB to 600GB, helping to mitigate the issue.
Phabricator is gradually winding down. Maintaining a website withover 600K lines of PHP code is not sustainable. As a result, ourcommunity is in need of a suitable replacement. GitHub's pull requestsystem have been selected as the alternative. I belong to the group thatshares concerns regarding the quality of GitHub's pull request system.My primary worries include:
Efficient subscription: how do contributors effectively subscribe topatches they are interested in?
Review time for less prepared patches: will these patches consumemore time from established reviewers?
Rubber stamping: will we witness an increase in rubber stamping, orwill many patches be approved that would have otherwise been rejected byexperienced reviewers for valid technical reasons?
Moreover, the GitHub Pull Request system utilizes a model that someconsider flawed. It represents a patch as a difference between commits,rather than using plus/minus hunks. Unfortunately, this flaw has causedworkflow friction, leading to concerns like the belief that "forcepushing on the patch branch" should be avoided.
Ultimately, the individuals investing their efforts will have asignificant say in determining the replacement. We that are concerned ofGitHub pull will aceept the result, but I hope that the level of harmcaused by the less-capable system is deemed acceptable.
Appendix:the number of accepted/rejected patches by username for this releasecycle
I did a SQL query to find the numbers of accepted/rejected patches byPhabricator username between the two tags llvmorg-17-initand llvmorg-18-init(181 days), which roughly corresponds to the LLVM 17.x releasecycle.
1
select u.username, count(distinct r.lastActionDIffPHID) from differential_reviewer r join phabricator_user.user u where r.reviewerStatus in ('accepted','rejected') and1674629847<=r.dateCreated and r.dateCreated<1674634847and r.reviewerPHID=u.phid groupby r.reviewerPHID;
We have reviewers who are diligent in accepting/rejecting patches,and others who prefer to provide comments rather than changing the stateto accepted/blocked. In any case, a big thanks to all those who reviewcode as well as the contributors!