From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.24]) by sourceware.org (Postfix) with ESMTPS id 058703858D35 for ; Tue, 23 May 2023 18:41:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 058703858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gjlay.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=gjlay.de ARC-Seal: i=1; a=rsa-sha256; t=1684867297; cv=none; d=strato.com; s=strato-dkim-0002; b=giVV3ebzdOCO4+rTCkdKQ4NeQ0z2hYfObQeTGqd73FMrDbqngw3WCVD4hlj5IT1sF0 oAadJfpw0oyPxEGoomJp2hR18pN1Ia3gTlRViN/zojBEsIAl78DfJ7tA2Hj9KsnSffa/ zXkzTYzglzLix6leR3XD8NgwZ1Q0DSCwMeqO/EHq9Vaf6oaOCqdSUSXr9XDwjalwq6Kl XItDJa0M8axhSKJg0mTSVFX128l2VAcMgUpR2ouIHnNKTlIYo8e95JlEiD+tA9KgpL11 4WUAJxch9iLmhqZRGgx0SAvieQJgxdmOegUAe1907zBRZpQ6n1wM3Sd/aCwFwJiCakXr 85SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1684867297; s=strato-dkim-0002; d=strato.com; h=Subject:From:To:Date:Message-ID:Cc:Date:From:Subject:Sender; bh=mZpZJRBCabZOC5OBycsPU4Bq3yxhNnsUn6D0FVbIr7I=; b=b81o+xE1N1vgc3opB8T0a9Ogsr9pBjxsKk+11Ak6d+1Wj5cAI2rU0UxxveQy3KJcuE jyidH33XRDN96GpLmkd+yRnNyjWVBTho8CSm+bwJLEnKL38ZV9oCHKtHYvAMz/d6/h3y FMIO2wjyHUAeY6akvECtjDHdSSe1fceWvrKtxknjNaWVSbEiV+CdPHY/WeGdA1+SHBWD hYPoEpZaZlJ9wL89+GWo65zCTeboleNdDOTMq1hLZfYMnl7/KgOOgBpkiUhuDuK6/wOG SNI4R3TlQT5XAi+yxUtJojcEeHOoj66WwbZAwHErYupSuXxu4+FFZfT8oEkzW8jKC+71 etVQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1684867297; s=strato-dkim-0002; d=gjlay.de; h=Subject:From:To:Date:Message-ID:Cc:Date:From:Subject:Sender; bh=mZpZJRBCabZOC5OBycsPU4Bq3yxhNnsUn6D0FVbIr7I=; b=FKOAlokVYjMgRqvtEzT1T9Vqnrj/ao+ICmfq4Hg9WJ/C0Z/TqZl7YC/kXDP1gO3lR7 v0mVphkEQyyh9xF4WOUUOpg0U3c5Pniyh5SlGx4xOltdpMWqkT34iJveld6g99xRtOdn rNX7V3ZY1RtjCaH8IHE5YznpCzU4vsNE11nKKC7ilEoNxg8j+S938ZHFTUjl+KNdPaqY C3V5noF/cSXym18aFl6qewX6InNEPo0LPMK/Y6eey0bNXhcJN3vpF3YhCMx6DdpiKflv GBUCRy8wPcCEvEk74261jWom5lp4xCD6lh+WD3d5kTtCbhhJA18zxWBh/UqQ+JwvtNc7 8TVw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1684867297; s=strato-dkim-0003; d=gjlay.de; h=Subject:From:To:Date:Message-ID:Cc:Date:From:Subject:Sender; bh=mZpZJRBCabZOC5OBycsPU4Bq3yxhNnsUn6D0FVbIr7I=; b=Z8BGin+KV0pTOO/R3p1tH/t2lSGdwZ1qtMJkL91TQytSoCdjd7fLt+IMTyHfa6NBW7 8uXdfVrNg15rENTdJxDw== X-RZG-AUTH: ":LXoWVUeid/7A29J/hMvvT3koxZnKT7Qq0xotTetVnKkRmM69o2y+LiO3MutATA==" Received: from [192.168.2.102] by smtp.strato.de (RZmta 49.4.0 DYNA|AUTH) with ESMTPSA id z691f1z4NIfbgz7 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Tue, 23 May 2023 20:41:37 +0200 (CEST) Message-ID: <1ed99189-7db3-6b97-db6b-86ce295c075a@gjlay.de> Date: Tue, 23 May 2023 20:41:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: gcc@gcc.gnu.org From: Georg-Johann Lay Subject: Wrong cost computation / conclusion ins insn combine? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: For some time now I am staring at the following test case and what combine does with it: typedef struct { unsigned b0 : 1; unsigned b1 : 1; unsigned b2 : 1; unsigned b3 : 1; unsigned b4 : 1; unsigned b5 : 1; unsigned b6 : 1; unsigned b7 : 1; } b_t; Prior to combine, there is: insn_cost 4 for 18: r52:QI = r24:QI insn_cost 4 for 2: r47:QI = r52:QI insn_cost 4 for 6: r48:QI = zero_extract(r47:QI,0x1,0) insn_cost 4 for 7: r50:QI = 0x1 insn_cost 4 for 8: r49:QI = r48:QI ^ r50:QI insn_cost 8 for 9: zero_extract(r47:QI,0x1,0) = r49:QI insn_cost 4 for 15: r24:QI = r47:QI So insn 6 extracts bit 0, insn 8 flips it, and insn 9 inserts it as bit 0 again. Combine then starts looking for combinations, and at some point comes up with: Trying 7 -> 9: 7: r50:QI = ~r47:QI 9: zero_extract(r47:QI,0x1,0) = r50:QI Successfully matched this instruction: (set (zero_extract:QI (reg/v:QI 47 [ a ]) (const_int 1 [0x1]) (const_int 0 [0])) (not:QI (reg/v:QI 47 [ a ]))) allowing combination of insns 7 and 9 original costs 4 + 8 = 12 replacement cost 12 deferring deletion of insn with uid = 7. modifying insn i3 9: zero_extract(r47:QI,0x1,0)=~r47:QI deferring rescan insn with uid = 9. So the cost is 12 and this insn is accepted. But down the line, combine cooks up this: Trying 2, 9 -> 15: 2: r47:QI = r52:QI 9: zero_extract(r47:QI,0x1,0) = ~r47:QI 15: r24:QI = r47:QI ... Successfully matched this instruction: (set (reg/i:QI 24 r24) (ior:QI (and:QI (reg:QI 52) (const_int -2 [0xfffffffffffffffe])) (and:QI (reg/v:QI 47 [ a ]) (const_int 1 [0x1])))) allowing combination of insns 2, 9 and 15 original costs 4 + 12 + 4 = 20 replacement costs 4 + 12 = 16 deferring deletion of insn with uid = 2. modifying insn i2 9: r47:QI=~r52:QI deferring rescan insn with uid = 9. modifying insn i3 15: r24:QI=r52:QI&0xfffffffffffffffe|r47:QI&0x1 deferring rescan insn with uid = 15. So this one has a cost of 16 which is more expensive than the first combination. For example it still needs to flip the bit. So why is combine choosing the expensive replacement over the cheap one? Also it combines hard-registers in the 2nd case, but not in the 1st one. So the costs get biased towards 2nd. Can someone explain why combine takes the more expensive solution? Target is avr, compiled with $ avr-gcc-14 bits.c -dumpbase "" -S -Os -fdump-rtl-combine-details -dp Johann