pr-subcribers-vectorizers
llvm/lib/Transforms/Vectorize
I’d like to be subscribed to anything happen in Clang
How about
pr-subscribers-clang
clang/**
We are probably going to need more fine grained control for clang-format, tools, analysis/cfg, ast matchers, etc… (codegen was already mentioned) but an all compasing group does seem useful
Might be good to have the following:
pr-subscribers-testing-tools
llvm/include/llvm/FileCheck/*
llvm/lib/FileCheck/*
llvm/test/FileCheck/*
llvm/unittests/FileCheck/*
llvm/utils/lit/*
@jdenny-ornl Am I missing anything?
Perhaps worth adding the tiny utilities like split-file
, not
and count
under llvm/utils
to that list too, since they’re only used for lit testing.
Need a pr-subscribers-debug-info as well.
The dumpers and related tools are pretty well isolated, but there are individual files associated with formats and debug-info generation. Actually generation is kind of hard to nail down because it infects so much else. Here’s an initial pass; I suspect @dblaikie and @adrian.prantl may have other suggestions.
The directories for the dumpers and related tools look like:
llvm/include/llvm/DebugInfo
llvm/lib/DebugInfo
llvm/tools/dsymutil
llvm/tools/llvm-debuginfo-analyzer
llvm/tools/llvm-dwarfdump
llvm/tools/llvm-dwarfutil
llvm/tools/llvm-dwp
llvm/tools/llvm-gsymutil
llvm/tools/llvm-pdbutil
Possibly also
llvm/tools/llvm-debuginfod
llvm/tools/llvm-debuginfod-find
Might as well include all of
llvm/lib/CodeGen/AsmPrinter
(it’s not all about debug info, but a whole lot of it is)
Individual files, I’m sure I’ve missed some:
clang/lib/CodeGen/CGDebugInfo.cpp
llvm/include/llvm/BinaryFormat/Dwarf.*
And let’s not forget the testing directories!
llvm/test/DebugInfo
llvm/test/tools/dsymutil
llvm/test/tools/llvm-debuginfo-analyzer
llvm/test/tools/llvm-debuginfod
llvm/test/tools/llvm-debuginfod-find
llvm/test/tools/llvm-dwarfdump
llvm/test/tools/llvm-dwarfutil
llvm/test/tools/llvm-dwp
llvm/test/tools/llvm-gsymutil
llvm/test/tools/llvm-pdbutil
Thanks for working on this. A few more:
llvm/utils/FileCheck/**
llvm/docs/CommandGuide/FileCheck.rst
llvm/docs/CommandGuide/lit.rst
llvm/docs/TestingGuide.rst
This test seems misplaced:
llvm/test/Other/FileCheck-space.txt
Not sure about the various FileCheck directories under llvm/utils/gn/secondary/llvm.
Agreed.
pr-subscribers-github-workflow for everything under the .github directory might be good.
@MaskRay, this made me realise that the binary utils one should include the corresponding documentation too (including documentaiton for aliased executables like llvm-addr2line or llvm-strip).
@pr-subscribers-flang-driver
flang/tools/flang-driver
flang/unittests/Frontend
flang/lib/FrontendTool
flang/lib/Frontend
flang/include/flang/Frontend
flang/include/flang/FrontendTool
flang/test/Driver
Thanks!
Need a pr-subscribers-debug-info as well.
Also: llvm/lib/IR/Debug*.cpp
llvm/include/llvm/IR/Debug*.h
Please create pr-subscribers-m68k-backend
With the following directories / files:
llvm/lib/Target/M68k
clang/lib/Basic/Targets/M68k.*
clang/lib/CodeGen/Targets/M68k.cpp
Thank you!
Thanks @tstellar !
Here are the teams for libc++, libc++abi and libunwind:
@pr-subscribers-libcxx
libcxx/
runtimes/
@pr-subscribers-libcxxabi
libcxxabi/
runtimes/
@pr-subscribers-libunwind
libunwind/
runtimes/
I know we chatted about those previously and I gave you slightly different paths, but those are the right ones to use.
Yes, this umbrella team is useful for folks who want to know everything in clang/. If GitHub CODEOWNERS file faithfully provides gitignore style features, we can use this command to check whether a pattern works. Note that **
at the end can be omitted:
% grep /clang/\$ .gitignore # add a pattern locally for experiments
/clang/
% git check-ignore -v --no-index clang/lib/Basic/Attributes.cpp
.gitignore:74:/clang/ clang/lib/Basic/Attributes.cpp
Added these:
/llvm/docs/CommandGuide/llvm-*
/llvm/include/llvm/ObjCopy/
/llvm/lib/BinaryFormat/
/llvm/lib/DebugInfo/Symbolize/
/llvm/lib/ObjCopy/
/llvm/lib/Object/
/llvm/test/Object/
Certain files are not related to binary utilities, but most are related. Having a high recall rate is probably more important.
@MaskRay, this made me realise that the binary utils one should include the corresponding documentation too (including documentaiton for aliased executables like llvm-addr2line or llvm-strip).
For doc, I added llvm/docs/CommandGuide/llvm-*
for now. It’s probably too cumbersome to add every individual llvm-*.rst
file… (and there is no brace expansion)

I’m tempted to suggest a yaml2obj/obj2yaml team too, but that should probably be independent. WDYT?
How about the following?
/llvm/include/llvm/ObjectYAML/
/llvm/lib/ObjectYAML/
/llvm/test/tools/obj2yaml/
/llvm/test/tools/yaml2obj/
/llvm/tools/obj2yaml/
/llvm/tools/yaml2obj/

Can individual files be added to a team? I’d like, for example, an “clang AArch64” team that covers various bits of clang, but none of those bits are in a distinct directory. Similarly, a “SCEV” team that covers the core bits of ScalarEvolution/ScalarEvolutionExpander.
This makes me feel that we need a guideline or example what granularity we want.
The fragmentation seems more severe for backend teams.
For the AArch64 backend, there are miscellaneous files like
clang/include/clang/Basic/BuiltinsAArch64*
clang/lib/Driver/ToolChains/Arch/AArch64.*
clang/lib/CodeGen/Targets/AArch64.cpp
clang/lib/Basic/Targets/AArch64.*
llvm/docs/AArch64SME.rst
llvm/include/llvm/BinaryFormat/ELFRelocs/AArch64.def
llvm/include/llvm/IR/IntrinsicsAArch64.td
llvm/include/llvm/TargetParser/AArch64TargetParser.h
and many AArch64/
directories under a very specific test directory, e.g. llvm/test/Transforms/LoopUnroll/AArch64/
and llvm/test/LTO/AArch64/
@TNorthover @sjoerdmeijer @statham-arm
edit: I suggested the following on https://github.com/llvm/llvm-project/pull/65131 for every backend team as a starter:
/llvm/include/llvm/IR/Intrinsics$backend.td
/llvm/lib/Target/$backend/
/llvm/test/CodeGen/$backend/
/clang/lib/Basic/Targets/$backend*
/clang/lib/Driver/ToolChains/Arch/$backend.*
/clang/lib/CodeGen/Targets/$backend.cpp
/clang/include/clang/Basic/Builtins$backend*
Clang static analysis groups:
@pr-subscribers-clang-analysis (CFG, flow-sensitive analysis, analysis-based warnings)
clang/include/clang/Analysis/
clang/lib/Analysis/
@pr-subscribers-clang-static-analyzer (the clang static analyzer)
clang/include/clang/StaticAnalyzer/
clang/lib/StaticAnalyzer/
clang/tools/scan-build/
clang/utils/analyzer/
clang/docs/analyzer/
(I think this separation could be better, there’s significant overlap that would probably cause folks to over-subscribe. I’ll open a separate thread to discuss this, maybe we’ll come up with better groups?)
(edit: here’s the thread!)
Can we have a group for instrumentation and sample profile data:
@pr-subscribers-pgo
llvm/lib/Transforms/Instrumentation/*
llvm/test/Instrumentation/*
compiler-rt/lib/profile/*
compiler-rt/lib/memprof/*
compiler-rt/test/profile/*
compiler-rt/test/memprof/*
llvm/tools/llvm-profdata/*
llvm/tools/llvm-profgen/*
llvm/test/tools/llvm-profdata/*
llvm/test/tools/llvm-profgen/*
llvm/unittests/ProfileData/*
I think that covers all the PGO specific parts we have. Please chime in if there is more to add to this list.
cc @davidxl @WenleiHe

llvm/lib/Transforms/Instrumentation/*
Per About code owners - GitHub Docs , you can remove *
at the end.
/llvm/lib/Transforms/Instrumentation/
matches *Sanitizer*
files, which is probably not desired. This list may work better:
/llvm/lib/Transforms/Instrumentation/CGProfile.cpp
/llvm/lib/Transforms/Instrumentation/ControlHeightReduction.cpp
/llvm/lib/Transforms/Instrumentation/IndirectCallPromotion.cpp
/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
/llvm/lib/Transforms/Instrumentation/PGO*
/llvm/lib/Transforms/Instrumentation/ValueProfile*
/llvm/test/Instrumentation/InstrProfiling/
/llvm/test/Transforms/PGOProfile/