On 9/25/26 3:13 PM, Aldy Hernandez wrote:
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.
Im probably going to gain back some performance as well with a couple of
pending changes, so its all good :-)
Andrew
