From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2953A3857838; Mon, 30 Oct 2023 16:19:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2953A3857838 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1698682743; bh=Rs9PWJA+4+lhyjSE9C+sfvqGZynbiOeANG2TVw/tsIQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gTMeCZr7qnNEqOeFEon1YcONrP+OhwdoK6n/sSTAaWVT4699vws1zAgg/qL7aQmLk 4NLGB2Tn7c8uji6fJhAT3g/ZidBs5VqdBlcUhm7X28n203RjD78MxXt/vfykG4/7a+ lBb4WrrA0cRJLgBhk76SC0sSf1poJTM4tDTZz+mY= From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/106594] [13/14 Regression] sign-extensions no longer merged into addressing mode Date: Mon, 30 Oct 2023 16:19:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: missed-optimization, patch X-Bugzilla-Severity: normal X-Bugzilla-Who: segher at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.3 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=3D106594 --- Comment #27 from Segher Boessenkool --- (In reply to Roger Sayle from comment #21) > Segher has proposed that object code size correlates with the quality of It isn't a proposition, it is a simple and obvious fact. But, this isn't exactly what I say :-) Code size strongly correlates with number of instructions, almost 1-1 on mo= st targets. Number of instructions is exactly what combine tries to reduce. Whether that makes the code actually better is something completely separat= e as well. If your instruction cost function (and please use insn_cost, it is m= uch easier to use, and thus gives better results than rtx_costs) is good, this = of course should work fine. And there is a hook (TARGET_LEGITIMATE_COMBINED_I= NSN) for the very nasty cases. But the whole "fewer insns that do the same thing, is better" thing is not actually true on some targets. Such targets are incredibly hard to optimise for. There is no way combine can do a good job for such targets. It is incredibly hard for human programmers to write good machine code for such systems by hand as well. I do use object code size **of a huge sample** as a quick and dirty sniff t= est to see if a change to combines is good or bad. After that I always look at= the actual changes as well. I do realise all pitfalls associated with this :-)=