On 8/31/26 8:42 PM, Robert Guthrie wrote:
On Sun, Aug 30, 2026 at 10:43:22PM -0600, Jeff Law wrote:
I'd be looking at cfgcleanup.cc, cfgrtl.cc and bb_is_just_return for
inspiration.
Thank you, I think I am on the right track then: my solution was
making use of bb_is_just_return,
though it failed to bootstrap and I haven't figured out why yet.
A failure to bootstrap is often painful to debug. What I often do in
those scenarios is configure with "--disable-bootstrap", build without
the patch and run the testsuite. Save off the results. Apply patch, run
the testsuite again and compare with prior run. That'll often get you a
simpler test than trying to walk backwards from a stage2 or stage3 failure.
Yes, I realize this is a very minor code-size improvement at best,
but it has been quite good for digging in to GCC for the first time,
learning how to inspect/manipulate the CFG, RTL, etc.
It's likely harder than a typical "simple hack of the week" as those
often end up being target patterns or match.pd patterns -- so limited in
how many APIs you need to understand, much less RTL or gimple IL
parsing, etc. But there's folks here that can help.
I've requested a bugzilla account and I will file one once that is thru.
Sounds good. Thanks. Feel free to add me on CC once the bug is open.
I track all RISC-V bugs for the weekly patchwork meeting (Tuesday
mornings US time, happy to get you an invite if you want). We focus on
making sure submitted patches have someone assigned for review, state of
the CI systems, usually a handful of bugs to make sure get proper
attention, and any general discussion that we need for RISC-V issues.
We often also touch on glibc or binutils issues, particularly as those
projects approach releases.
It might be a good "simple hack of the week" candidate: I am only
looking at it
a little each night after the kids are down, so someone can probably
beat me to it :)
Someone probably could, but right now it's yours to chase. In theory
there's a detection phase, then the transformation phase. Transformation
is conceptually simple. Delete the return in the earlier block and
reflect in the CFG that the earlier block falls into the later block.
Jeff
