On Fri, Sep 25, 2026 at 01:32:22PM -0400, Andrew MacLeod wrote: > > On 9/25/26 12:02 PM, Aldy Hernandez wrote: > > On Thu, Sep 17, 2026 at 03:57:25PM +0200, Aldy Hernandez wrote: > > > On Fri, Sep 11, 2026 at 10:44:41AM +0200, Aldy Hernandez wrote: > > > > On Thu, Sep 10, 2026 at 09:46:22AM -0400, Andrew MacLeod wrote: > > > > > On 9/10/26 5:48 AM, Aldy Hernandez wrote: > > > > > > [Andrew, are you OK with this? It seems simple enough, but I may be > > > > > > missing something subtle, or perhaps there is another place in the > > > > > > compiler we should be fixing this? Either way, it seems something > > > > > > good to implement for completeness sake. OK for trunk?] > > > > > > > > > > I'm OK with it... just check the performance... it'll probably > > > > > trigger a > > > > > bunch more edge range calculations... At some point it might be worth > > > > > adding some kind of indication to range-ops when a routine is "the > > > > > default". For instance, if op1_op2_relation is the default for > > > > > handler, > > > > I'm torn here. > > > > oVRP gets 0.8% slower, but the threader gets 3.4% slower. All because > > > > register_outgoing_edges is now 36% slower with the extra edge ranges. > > > > > > > > I have some good will I've bought in the back threader, but it's > > > > annoying. I was hoping to use the good will with some sort of value > > > > numbering to help us get memory stuff in the threader. > > > > > > > > This catches real things I've run into, but honestly not > > > > that many. Up to you. > > > > > > > > Aldy > > > PING > > PING PING. > > > > Oooh, and now with a PR: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127485 > > yeah the performance issue is unfortunate. Its basically > register_outgoing_edges () now doing 14% more work. With your patch, that > is the only currently implemented op1_op2_relation() that is not a boolean > result. so all that extra work is for that one thing. And It triggers in < > 0.5% of cases we'd buy ourselves extra good will if we had other > op1_op2_relation () implementations because utilizing them will cost very > little extra and help to amortize the cost.. > > However, that said, since there is a PR, I'd say we should commit it.
Thanks, committed.
