From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay4-2.pub.mailoutpod1-cph3.one.com (mailrelay4-2.pub.mailoutpod1-cph3.one.com [46.30.212.3]) by sourceware.org (Postfix) with ESMTPS id 9668D383575A for ; Thu, 23 Jun 2022 06:01:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9668D383575A 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:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:from; bh=lu6vnnKN2RgE8N/gdF8xCZiFhxJ09Lz2qzoUz1VPZDA=; b=acbiNh+7er5Z2iXHepU5TfOL0ZnBu41oWEDep2J2J5sd6dWSPPXr9slYko9Z4PKig841J18Dre+CQ qEuKwMSZCL/I8wwtkmZwtWfKPCWG8CbmEM3spPtzvDzlF90m0TCaXmlufGPIRvFMsKSVopz0Csoh3h KlhyY1LLT/3DJ8Unxjp6QmeWCHG91xXaKPHvSAjxQ/imp27MiVsQBHXIb6O59rLDS4QqpKKDFXf82P H6YTfT39WrE2+l3ku7jcBZKMmrnmK1L4d/0gKurMb+eKlvpsNwIVPJmVc+f4AdQGiVA/7L2ruVuzT8 8l8HDxDCkoQMYTx2d5Pg0Ka1LqKnp8w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=bitsnbites.eu; s=ed2; h=content-transfer-encoding:content-type:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:from; bh=lu6vnnKN2RgE8N/gdF8xCZiFhxJ09Lz2qzoUz1VPZDA=; b=+6MSOS3lpTPIw53gC77JhEUBP4bHiokN2Oua2B1/A2gLjbqpRlnxPeMRgzRL3il/eOvVYJx9UPEaL +8ZZyIRDQ== X-HalOne-Cookie: bbb4d6525baf15da2b49119a16182b0fc363fea4 X-HalOne-ID: f08550f4-f2b9-11ec-8232-d0431ea8bb10 Received: from [192.168.2.43] (h-85-24-213-173.a392.priv.bahnhof.se [85.24.213.173]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id f08550f4-f2b9-11ec-8232-d0431ea8bb10; Thu, 23 Jun 2022 06:01:36 +0000 (UTC) Message-ID: <41b4cfd1-b4a0-8093-6de7-0bfd2d70be62@bitsnbites.eu> Date: Thu, 23 Jun 2022 08:01:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [MRISC32] Not getting scaled index addressing in loops Content-Language: en-US To: Andrew Pinski Cc: GCC Mailing List References: <25bdaf9d-fe54-48c9-d1a8-4a88325253c6@bitsnbites.eu> From: m In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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 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: Thu, 23 Jun 2022 06:01:41 -0000 On 2022-06-22, Andrew Pinski wrote: > On Fri, May 27, 2022 at 11:52 PM m wrote: >> 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. > The problem is your cost model for the indexing is incorrect; IV-OPTs > uses TARGET_ADDRESS_COST to figure out the cost of each case. > So if you don't have that implemented, then the default one is used > and that will be incorrect in many cases. > You can find IV-OPTs costs and such by using the ivopts dump: > -fdump-tree-ivopts-details . > > Thanks, > Andrew Pinski Thank you Andrew! I added a TARGET_ADDRESS_COST implementation that just returns zero, as a test, and sure enough scaled indexed addressing was used. Now I will just have to figure out a more accurate implementation for my architecture. Regards,   Marcus > >> Does anyone have any hints about what could be wrong and where I should >> start looking? >> >> Regards, >> >> Marcus >>