From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 7D8B83858C2A; Wed, 30 Aug 2023 14:04:13 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7D8B83858C2A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1693404253;
	bh=90DM0vQH+2hTg0lqG//GYoUe62KhwU4b78Mt1Xjv5AI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=SGrk68/BC7d4PzD334aTg5JlAQLSjz0yLbH+1nIUyPYhPolzpMPnA7Bp8oNc3F3hC
	 SFdRflp000MLTUAC1KH6m9lu6TbO0VrUvpZlbWdYRZjnoVPFaCMeQ4KRtlH1k+e1nk
	 21nj6YRWyLKh1k7qYDrTfTmRretEJXZSFxJcvaM0=
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/110093] [12/13/14 Regression][avr] Move frenzy
 leading to code bloat
Date: Wed, 30 Aug 2023 14:04:12 +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: 14.0
X-Bugzilla-Keywords: missed-optimization, needs-bisection, ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vmakarov at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110093-4-vxg5tXfh79@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110093-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110093-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110093

--- Comment #5 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Georg-Johann Lay from comment #4)
>
>=20
> So are you saying that the bug is actually in lower-subreg.cc ?

No. lower subreg is fine.

Sorry to be unclear.  To generate a better code for the current test case (=
or
analogous cases) we need live analysis on sub-register level.  Currently it=
 is
done only on whole pseudo-register level.

  First of all DFA (data flow analysis framework) should be modified.  As I
showed DFA wrongly calculate that pseudo r44 lives at the start of BB2,
although it is not (r44 value is not used before insn #37).  It is a big jo=
b.=20
The problem is also that the active development of DFA stopped long time ago
and their developers do not work on gcc anymore.

  Secondly, after DFA modification RA (and may be other optimizations) shou=
ld
be modified to work with this information on BB-level.  It is a medium size
project for me and probably it would take 2-3 months of my work time.

So looking at this situation, I would suggest to make -fno-split-wide-types=
 a
default for AVR target to solve this and and analogous PRs.  May be it is n=
ot
necessary for good performance of real avr applications.  I am not user AVR=
 and
can not say how severe this problem for the real applications.=