On 10/21/26 12:08 PM, Joseph Myers via Gcc wrote:
On Wed, 21 Oct 2026, Uros Bizjak via Gcc wrote:
2. Run an AI-assisted review where available. Give the tool real
context, not only the diff: the surrounding code, the relevant machine
description or front-end code, and the testsuite results. Reviews of a
bare diff are much shallower.
If we want to suggest AI-assisted review then I think we should provide
functionality in the forge (this could be some kind of bot that looks for
particular comments and acts on them, it doesn't need any heavy
integration) for "do an AI-assisted review and show me the results
privately" and "do an AI-assisted review and post the results to this pull
request". (Where it's not the responsibility of the individual
contributor to provide the AI or the instructions to the AI on how to
carry out the review.)
"show me the results privately" could be used both by the original
contributor (reduce the noise in the pull request from successive
iterations and AI reviews until they consider it to be ready for human
review), and by someone reviewing the pull request (who then examines the
AI results and decides which of them are worth surfacing for the attention
of the original contributor, rather than giving the contributor unfiltered
AI output they didn't ask for).
I think Sashiko can do that. I suspect under the hood that the forge
can apply a patch to a repo which all one would need for Sashiko since
I'm 100% certain it can review a commit from a repo. In that mode
results come on stdout rather than on a web page, so we route that final
output to the user privately.
Note that this means community-agreed review rubrics rather than each
person having their own idea of what's a suitable review (and beginners
probably not having a very good idea of what instructions to give).
Absolutely. And that's what I'm working on in my copious spare time --
I'm starting fairly narrow, but the basic idea is to come up with good
documentation on how to review a patch to a machine description. That
can be used by the submitter to know what implementation details the
review will look at, the reviewer to make sure they don't miss anything
and of course an LLM.
So things it's currently looking for include mismatched semantics on
patterns, invalid accessor usage, operator vs operand mode sanity, avoid
pass specific tests in insn conditions, etc. It's not ready yet, but
it is progressing daily. Most of the recent RISC-V bitmanip.md changes
are a result of using that review rubric to evaluate correctness of
every pattern in that file.
Jeff
