From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay3-2.pub.mailoutpod1-cph3.one.com (mailrelay3-2.pub.mailoutpod1-cph3.one.com [46.30.212.2]) by sourceware.org (Postfix) with ESMTPS id 7F18E385608E for ; Sat, 28 May 2022 06:51:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7F18E385608E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bitsnbites.eu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=bitsnbites.eu DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitsnbites.eu; s=rsa2; h=content-transfer-encoding:content-type:subject:to:reply-to:from:mime-version: date:message-id:from; bh=fonP7tyEVHXYiP5rGX2HmADLmQiV30nLCtss5tDBfAo=; b=aImP+9zrZYe9RnDqm83NXiZBpvtCeX7MEqKAbAMRngSd3//OGuvJEf4rPAe6pNgf50qSO52Zz5wzq RcGFnTHXtu05wch5GAcvCoe4HKQ7vBrn9ZnfMzK9j05+CuCn1sOTPl1Ttgr8f/0vy5x6LFGcIaIRrn qLoqYfUJHdI/z98OmvpKfYq/orvDyQcyBBTUF1CcaWlnDp0cOiaFCPzFoz6WPShoLJqGBazHbepXD+ ojWYbRWsNf4V0IUDHOsKigfxzKcOqHcLeO/ikpZx4FCbbtkvA2FRR3IEC/vkNLDQLGLyrgyJhi42hW IHV/+5la4VLjND3DIKj1Ml3r/tqe1yw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=bitsnbites.eu; s=ed2; h=content-transfer-encoding:content-type:subject:to:reply-to:from:mime-version: date:message-id:from; bh=fonP7tyEVHXYiP5rGX2HmADLmQiV30nLCtss5tDBfAo=; b=6bcgnOwek4oDetHUTFQRViTL7bTuxPBV02gOeCcBjz9GwNpRbTuYa1ox8COVwbUTY/HBk9g7wa0M3 1rgLlcGBA== X-HalOne-Cookie: f2d9babcec66ab0fefffb0f0a3198d00ea866d1d X-HalOne-ID: 9a3e1053-de52-11ec-be76-d0431ea8bb03 Received: from [192.168.2.43] (h-85-24-213-173.a392.priv.bahnhof.se [85.24.213.173]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 9a3e1053-de52-11ec-be76-d0431ea8bb03; Sat, 28 May 2022 06:51:30 +0000 (UTC) Message-ID: <25bdaf9d-fe54-48c9-d1a8-4a88325253c6@bitsnbites.eu> Date: Sat, 28 May 2022 08:51:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 From: m Reply-To: m@bitsnbites.eu To: gcc@gcc.gnu.org Content-Language: en-US Subject: [MRISC32] Not getting scaled index addressing in loops Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2022 06:51:35 -0000 Hello! I maintain a fork of GCC which adds support for my custom CPU ISA, MRISC32 (the machine description can be found here: https://github.com/mrisc32/gcc-mrisc32/tree/mbitsnbites/mrisc32/gcc/config/mrisc32 ). I recently discovered that scaled index addressing (i.e. MEM[base + index * scale]) does not work inside loops, but I have not been able to figure out why. I believe that I have all the plumbing in the MD that's required (MAX_REGS_PER_ADDRESS, REGNO_OK_FOR_BASE_P, REGNO_OK_FOR_INDEX_P, etc), and I have verified that scaled index addressing is used in trivial cases like this: charcarray[100]; shortsarray[100]; intiarray[100]; voidsingle_element(intidx, intvalue) { carray[idx] = value; // OK sarray[idx] = value; // OK iarray[idx] = value; // OK } ...which produces the expected machine code similar to this: stbr2, [r3, r1] // OK sthr2, [r3, r1*2] // OK stwr2, [r3, r1*4] // OK However, when the array assignment happens inside a loop, only the char version uses index addressing. The other sizes (short and int) will be transformed into code where the addresses are stored in registers that are incremented by +2 and +4 respectively. voidloop(void) { for(intidx = 0; idx < 100; ++idx) { carray[idx] = idx; // OK sarray[idx] = idx; // BAD iarray[idx] = idx; // BAD } } ...which produces: .L4: sthr1, [r3] // BAD stwr1, [r2] // BAD stbr1, [r5, r1] // OK addr1, r1, #1 sner4, r1, #100 addr3, r3, #2 // (BAD) addr2, r2, #4 // (BAD) bsr4, .L4 I would expect scaled index addressing to be used in loops too, just as is done for AArch64 for instance. I have dug around in the machine description, but I can't really figure out what's wrong. For reference, here is the same code in Compiler Explorer, including the code generated for AArch64 for comparison: https://godbolt.org/z/drzfjsxf7 Passing -da (dump RTL all) to gcc, I can see that the decision to not use index addressing has been made already in *.253r.expand. Does anyone have any hints about what could be wrong and where I should start looking? Regards,   Marcus