From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E08D43857C43; Fri, 16 Feb 2024 16:08:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E08D43857C43 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708099717; bh=anZGC4WeADj+mEkSBFZwQy9JIQW5WhIFcTFyqFGnHLE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gvh0fnVPeHTJKGmIzMopAkKqc7YODMoqtWjCVW0hIdqFrwo5hSp7OX7x4J6U+CsH9 bKdwxjtV/D7wTBu1+rPGpxCGJRq1NnsvuNffFUA+0bmWFsZESwFHd7hv/o67GWf+dI ffHjC3dm5UMMmuBRVhEet70AUsa1nk+mUo2PFHWI= From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41 Date: Fri, 16 Feb 2024 16:08:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned 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=3D113907 --- Comment #43 from Jan Hubicka --- > // See discussion here: > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html Discussion says: "Once legacy evrp is removed, this won't be an issue, as ranges in the IL=20 will tell the truth. However, this will mean that we will no longer=20 remove the first __builtin_unreachable combo. But ISTM, that would be=20 correct behavior ??." So perhaps, we could remove that special case for default def and phi? It is an odd thing and we clearly lose info here. The problem is that value of parameter i itself does not have global value range [0...10] so I need to compute new SSA name to get it preserved through ipa-split. Maybe ipa-split can be extended to fire up ranger and try to get better value ranges on function parameters from the split function header. Not sure if that is worth the effort though. If we go with merging functions with different ranges, we indeed need to update ranges and bits both in SSA_NAME infos and in ipa-prop's jump functions. At the time sem_fuction::merge calls ipa_merge_profiles we do have both function bodies in memory and thus we can do the job. If we just drop the info instead of merging, we do limited harm on SSA_NAME infos since they mostly will be recomputed again. For ipa-prop this may cause more interesting precision loss.=20=20 So perhaps for backportability we may want to just limit ICF to functions wth same ranges in SSA_NAME infos. Let me cook up a patch and see if there is significant loss in merged functions. I think it should be quite small given that ranges seem to only diverge through ipa-split in very specific cases for now. (and given how much time I spent on producing the testcase)=