From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from franke.ms (serveronline.org [136.243.37.185]) by sourceware.org (Postfix) with ESMTPS id 2411D3858C52 for ; Tue, 16 Jan 2024 20:02:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2411D3858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=franke.ms Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=franke.ms ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2411D3858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=136.243.37.185 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705435365; cv=none; b=NNw1Mzz7q5wfP8nVQAh9z0cEHrnYT1tqScUxJguGVDUDhqD81gcHBsuyrR3uP7o6yGzxSVPxqllcb+2g1HmNv3O79vKG/5gX20i3asTusPhLmj7m180G62SsbQ6mRoVys7TcrhkOZUiEt/P4/o4308Xvk8ZxWj6ZfxxBZL4/hX0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705435365; c=relaxed/simple; bh=oOP7Hsqqscv1nVZEoRM/DmzB8y/bbglRwm5y/Yoov70=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=hTKTxJ0Tur6bdSoZ5gloa11UJTnczDSqTenjNC87wKnNyQ/YOwNv8qWVy8l0BeQDs9KK3yuMw6Q4z+3jvPR7s9kTikmEXudHSgFaG6qx9fDuF2KTBLijAb0lO+c03oYGKFae02QAXkoYBidw5sKmWL3YbO964jNa8ZL0CAiSxig= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from HP (i59F6C2FF.versanet.de [89.246.194.255]) by serveronline.org (BEJY V1.6.12-SNAPSHOT (c) 2000-2021 by BebboSoft, Stefan "Bebbo" Franke, all rights reserved) with SMTP id 18d13de69ce6e866170707ddd6c from stefan@franke.ms for gcc-help@gcc.gnu.org; Tue, 16 Jan 2024 21:02:39 +0100 From: To: Subject: autoinc / postinc not used Date: Tue, 16 Jan 2024 21:02:38 +0100 Message-ID: <00ae01da48b6$f4e5ce80$deb16b80$@franke.ms> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01DA48BF.56AB6F00" X-Mailer: Microsoft Outlook 16.0 Content-Language: de Thread-Index: AdpIqo1C21fPxV2ET++cDKdJvnkp2g== X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multipart message in MIME format. ------=_NextPart_000_00AF_01DA48BF.56AB6F00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, =20 I work a lot with the good old m68k target where post-increment is supporte= d, and I was surprised that there almost no post-increments are used in the= generated code. This simple code: =20 void memclr (int length, long * ptr) { for(;length--;){ *ptr++=3D 0; } }=20 =20 does not use post-increments on AVR or SH. See also https://godbolt.org/z/f= Tvdv65rr =20 On M68K a post-increment appears: =20 memclr: move.l 4(%sp),%d1 move.l 8(%sp),%a0 move.l %d1,%d0 subq.l #1,%d0 tst.l %d1 jeq .L1 .L3: clr.l (%a0)+ dbra %d0,.L3 clr.w %d0 subq.l #1,%d0 jcc .L3 .L1: rts =20 If you change the code and add a 2nd statement to the loop: =20 void memclr (int length, long * ptr) { for(;length--;){ *ptr++=3D 0; *ptr++=3D 0; } } =20 the post-increment disappears: =20 memclr: move.l 4(%sp),%d1 move.l 8(%sp),%a0 move.l %d1,%d0 subq.l #1,%d0 tst.l %d1 jeq .L1 .L3: clr.l (%a0) addq.l #8,%a0 clr.l -4(%a0) dbra %d0,.L3 clr.w %d0 subq.l #1,%d0 jcc .L3 .L1: rts =20 =20 This is caused by several unfortunate conversions/optimizations. Here comes= the first: =20 The GIMPLE PASS converts post-increments by creating the next pointer befor= e the current pointer is used, which looks like =20 ptr.0 =3D ptr; ptr =3D ptr.0 + 4; *ptr.0 =3D 0; ptr.1 =3D ptr; ptr =3D ptr.1 + 4; *ptr.1 =3D 0; In the following steps this gets optimized further but in the end the addit= ion stays always in front of the last zero assignment and ends up to become= a +8. Since the +8 does not match the size also the first post-increment g= ets lost. And the last zero assignment is done with offset -4. That explain= s the generated code. =20 Now here comes my question: =20 Is there a more conforming/easier/better way to swap the generated gimple i= nstructions than patching gimplify_modify_expr and check for assignment pai= rs where the pointer-add can be moved behind the memory assignment? My hack is ugly: =20 gimple * p2 =3D gimple_seq_last_stmt(*pre_p); if (p2->code =3D=3D GIMPLE_ASSIGN && p2->prev && p2->prev !=3D p2) { gimple * p1 =3D p2->prev; if (p1->code =3D=3D GIMPLE_ASSIGN) { tree b =3D gimple_assign_lhs(p1); tree x1 =3D gimple_assign_lhs(p2); tree x2 =3D gimple_assign_rhs1(p2); if (b !=3D x2 && (TREE_CODE(b) =3D=3D VAR_DECL || TREE_CO= DE(x2) =3D=3D VAR_DECL || TREE_CODE(b) =3D=3D PARM_DECL || TREE_CODE(x2) = =3D=3D PARM_DECL) && ((TREE_CODE(x1) =3D=3D VAR_DECL && TREE_CODE(x2) =3D= =3D MEM_REF && TREE_OPERAND(x2, 0) !=3D b && (TREE_CODE(TREE_OPERAND(x2, 0)) =3D=3D = VAR_DECL || TREE_CODE(TREE_OPERAND(x2, 0)) =3D=3D PARM_DECL)) || (TREE_CODE(x1) =3D=3D MEM_REF && (TREE_CODE(x2) =3D= =3D INTEGER_CST || (TREE_CODE(x2) =3D=3D VAR_DECL && TREE_OPERAND(x1, 0) != =3D b))) && (TREE_CODE(TREE_OPERAND(x1, 0)) =3D=3D= VAR_DECL || TREE_CODE(TREE_OPERAND(x1, 0)) =3D=3D PARM_DECL))) { gimple_stmt_iterator to =3D gsi_last (*pre_p); gimple_stmt_iterator from =3D to; from.ptr =3D p1; gsi_remove (&from, false); gsi_insert_after (&to, p1, GSI_NEW_STMT); } } } =20 (there are more modifications necessary to create better code, but it=E2=80= =99s possible) =20 Thanks =20 Stefan =20 ------=_NextPart_000_00AF_01DA48BF.56AB6F00--