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 2BD803858D32; Sun, 24 Sep 2023 16:01:30 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2BD803858D32
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1695571290;
	bh=ek2ui5kLryCJHf1BNnJJ3tY+y6zBX5uYSkq2uppwqyI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=IeuTelkEF6v9LXGg9Jsfh1V+g27FjQHSYFwl84qVTt5eGlLMLvPzqMHsz9J65x9Iy
	 flQ5meGE/abEDGVEUOLaUDlpdSDmWlGRHO85IFOHHFY34o/yIPyu6oe0Oj77VatZgP
	 b02V+ssVOZoBFt95cNGquBo+gbFAFDtHP3tj5DnQ=
From: "652023330028 at smail dot nju.edu.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/111563] Missed optimization of LICM
Date: Sun, 24 Sep 2023 16:01:28 +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: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: 652023330028 at smail dot nju.edu.cn
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
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: <bug-111563-4-LY8jemtZuA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111563-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111563-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=3D111563

--- Comment #2 from Yi <652023330028 at smail dot nju.edu.cn> ---
(In reply to Andrew Pinski from comment #1)
> _5 =3D var_0_16(D) + var_6_18(D);
>   invariant up to level 1, cost 1.
>=20
> Basically because the cost is not high enough ...
>=20
> If you use   --param=3Dlim-expensive=3D1. then it will pull it out of the=
 loop.
>=20
> So the cost model is doing the correct thing here ...


Thank you very much for your prompt reply! It took me some time to confirm =
our
work. For Example 1, GCC does exactly what you say it does. But for Example=
 2,
it doesn't seem to work as expected.

https://godbolt.org/z/eeWThnqWs

Given the following code:=20
```c++
extern int var_24;
void test(int var_2, int var_3, int var_8, int var_10, int var_14) {

    for (int i_2 =3D -3247424; i_2 < 19; i_2 +=3D var_3 + 1056714155)=20
    {
        if(var_3){
            var_24 +=3D (-(200 / var_10)) + (-var_8);
            var_24 +=3D var_14 + var_2;
        }

        i_2+=3Di_2/3;
    }
}
```

We note that `(-(200 / var_10)) + (-var_8) + var_14 + var_2` as a whole can=
 be
treated as a loop invariant, but gcc-trunk -O3 --param=3Dlim-expensive=3D1 =
does
not:

```asm
test(int, int, int, int, int):
        mov     r10d, edx
        test    esi, esi
        je      .L1
        mov     eax, -200
        mov     edx, -1
        mov     r9d, DWORD PTR var_24[rip]
        add     r8d, edi
        idiv    ecx
        lea     edi, [rsi+1056714155]
        mov     ecx, -3247424
        sub     eax, r10d
.L3:
        movsx   rdx, ecx
        mov     esi, ecx
        add     r9d, eax                # ... + (-(200 / var_10)) + (-var_8)
        imul    rdx, rdx, 1431655766
        sar     esi, 31
        add     r9d, r8d                # ... + var_14 + var_2
        shr     rdx, 32
        sub     edx, esi
        add     ecx, edx
        add     ecx, edi
        cmp     ecx, 18
        jle     .L3
        mov     DWORD PTR var_24[rip], r9d
.L1:
        ret
```=