On 9/3/26 7:13 PM, Robert Guthrie wrote:
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.
That is true: it has been a little harder than I expected!
Since I am modifying cleanup_cfg, and it is called so many times,
I am getting a lot of weird interactions leading to infinite loops or
other errors. Or getting different behavior when it is called in
CFGRTL vs. CFGLAYOUT
mode (I spent last evening trying to grok the difference).
Maybe this is just something to tag onto the end of bbro rather than
adding it
to a core function instead?
But it fits fairly naturally in cfg cleanup and thinking more about it,
it should work irrespective of whether we're in cfg layout mode or not
if we do the cfg manipulations correctly.
The whole point of splitting out the two modes is to allow earlier
passes to ignore the low level mechanics of dealing with fallthru edges
and the like.
Conceptually a block ending in a return can have its return removed and
the cfg altered so that it has a fallthru edge to a block that has a
return and nothing else. This is true before and after cfg layout mode.
The refined wrinkle is you have to be past threading the
prologue/epilogue. It's only after that point that you know if you have
a trivial return or not.
So conceptually you could examine the predecessors of the exit block to
see if any of them are a trivial return. That's your target block. Of
the remaining predecessors, choose the one with the highest frequency
that has only a single outgoing edge reaching the exit block. Change
the edge to instead reach the new target block. You may have to mark it
as FALLTHRU, I don't remember offhand.
BTW, I haven't gotten a response from gcc-bugzilla-account-request
(not sure if that is typical,
I'm sure there is a lot of spam sadly) but I have not forgotten about it.
They were swamped with yet another DDOS earlier this week. They may
just be getting a little sleep.
Jeff
