From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C60D53858C2F; Mon, 15 Jan 2024 12:43:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C60D53858C2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1705322629; bh=5YbCxhd/Boos1qjZe/MVGoLLD0Uxi9XBjQShEVoYyGo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JuJ99eUMmruESw9/QHtEUmzbnpjp6FhHygRtStzsq7BftYFObeoo3zNH0XpRcN/rk QQ2jGULZmd35CWsvX3UElBNsqGxIOjXjFM4m/R00knz4FyrO1INO5JuNNtbt8yyDkc KZNh6TB97iajXUf36I1U04ecxcYcYW0HmXntmsVY= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1 Date: Mon, 15 Jan 2024 12:43:48 +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: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: --- 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=3D113372 --- Comment #9 from Jakub Jelinek --- (In reply to Richard Biener from comment #8) > I belive we investigated such workarounds but they didn't seem to work?=20 > Other > cases are concerned with address uses before loops (I think they start > lifetime "correctly" now) but CLOBBERs ending lifetime inside the loop. = The > dataflow problem then is confused with the backedge having the object not > live IIRC. >=20 > So what would your workaround do? Not handle address mentions as starting > live but only its (possible) memory uses? I meant in addition to the current cases which start uses (ADDR_EXPRs in the IL, loads and stores) also handle like that uses of SSA_NAMEs which can con= tain those ADDR_EXPRs. So, say add a mapping from SSA_NAME_VERSION to a bitmap (or vector?) of DEC= Ls and propagate through uses which addresses of decl they (may) refer to and = then when add_scope_conflicts_1 sees uses of those SSA_NAMEs, visit_conflict those to= o. So, say on the testcase from this PR, when seeing ivtmp.40_3 =3D (unsigned long) &MEM [(void *)&bitint= .6 + 8B]; mark 3 -> bitint.6 # ivtmp.40_39 =3D PHI mark 39 -> bitint.6 # ivtmp.28_40 =3D PHI mark 40 -> bitint.6 _147 =3D (void *) ivtmp.40_39; mark 147 -> bitint.6 ivtmp.40_38 =3D ivtmp.40_39 + 16; mark 38 -> bitint.6 _27 =3D (void *) ivtmp.28_40; mark 27 -> bitint.6 ivtmp.28_41 =3D ivtmp.28_40 + 16; mark 48 -> bitint.6 _98 =3D MEM[(unsigned long *)_147 + -8B]; don't do anything, this is a load from it, etc. if (ivtmp.40_38 !=3D _57) again, nothing, etc. _7 =3D (unsigned long) &bitint.6; mark 7 -> bitint.6 _57 =3D _7 + 600; mark _57 -> bitint.6 if (ivtmp.40_38 !=3D _57) nothing ivtmp.41_139 =3D (unsigned long) &MEM [(void *)&bitin= t.7 + 8B]; mark 139 -> bitint.7 # ivtmp.41_137 =3D PHI mark 137 -> bitint.7 _146 =3D (void *) ivtmp.41_137; mark 146 -> bitint.7 ivtmp.41_138 =3D ivtmp.41_137 + 16; mark 138 -> bitint.7 .DIVMODBITINT (0B, 0, &bitint.6, 6384, &D.2796, -8, &y, -6384); nothing _108 =3D MEM[(unsigned long *)&bitint.6 + 592B]; nothing, etc. Basically, only handle statements which can propagate address (or pointer-s= ized integer based on it) of a tracked variable or pointer arithmetics based on = that to other SSA_NAMEs. Of course, big question is what kind of propagation to use for that.=