From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C4F253857734; Thu, 11 May 2023 04:22:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C4F253857734 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683778938; bh=3ntUFuE+9JpYOmj6s9OnAJ6T7EAIPX7pRJ6xTL1hlEI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qKSwU9zJezg1C6Uo8XpL/Y/sfVVqSts6I4+jBii3hnTG+h0GxdiIm3Nu/qyGfR7KU QXNokFAknu7uhf1gCbyGyOri85czZ9VXsCzKKW/eixazAbOpPQA9mNFZXHDt6cqAfy cmUdPGlqW0PQv6pgQEZEVHxTE7WEsegsgrMUh7QE= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e Date: Thu, 11 May 2023 04:22:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: aldyh at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109695 --- Comment #34 from Aldy Hernandez --- Excellent ideas! For that matter, we may get away with defaulting to 3 sub-ranges and always resizing as needed (up to MAX). Needing more than 3 sub-ranges is so rare (less than 0.5% of the time), that the penalty will be small. Furthermore, these defaults are sensible enough that we could nuke int_rang= e altogether and have irange have this small [3*2] array. After all, most us= es of int_range now are int_range_max, since we never know the size of the range (except in rare cases such as boolean_type_node, etc). This would simplify the code and get rid of the annoying templates which I hate. No n= eed for int_range_max, or int_range, etc. Just plain irange. This would give us an irange of 592 bytes compared to 40912 for int_range_m= ax currently. Plus, it's not that far away from int_range<2> which currently = is 432 bytes, and as I mentioned, barely happens as we mostly use int_range_ma= x. I think this is a nice trade off. Cleaner more flexible code, without templates. Oh... preliminary tests show it's a 5% penalty for VRP, which is more than covered by our 13.22% improvement (plus Andrew's cache improvements) to VRP= .=