From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 4F1173858284 for ; Wed, 22 Jun 2022 19:54:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F1173858284 Received: by mail-lj1-x22f.google.com with SMTP id n15so9052924ljg.8 for ; Wed, 22 Jun 2022 12:54:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5xYpdUYn8KAO4NMjFjKxeiRpUNGVutRQ87jLf9cHjfg=; b=rbMp7edLxXJgU6fJcir9suTbm0pIthmo9cfO7Yur4gdGX/BnNzIzuB9RlBEfYmAjKN euhq+7Hg+20KxxNfBHfK2Cy8JOF932/rx4PRb51XzNjLI2homD8UR7CUMlj4ZdccSC4L 4tfLMO0JM9z5T+7qplNgXKce/2HmQu3P5m8QUqWIVQ6L2X25+tVmmFbFGvzVZS375UFt eSyP4BDD1ktZefojtE22JKhmV03GMte1xwPk10/CB/jd+uFfiezwX1cs5gKJOyXEbKSR HQxRZxExH1GqfW1LSl8fLjmMnAiysydx9+kk5EzmCHGlaw5lPGIHa3WjaMn2x+zvpgHf pltw== X-Gm-Message-State: AJIora/1lfHtKFTasEnFJjPKX2xN+AEr8yogK7z7bQFQN05dYhQ7p1kr P15L57Fp5gulQT7kg1Pd/lhXjocX+I635vStZoA= X-Google-Smtp-Source: AGRyM1tnLhSDhIt0wGcgTRP2GR3TiY/lvMM4gvk9xsCttoRILAOdJouV2ppj6iQ7sOkpTyGZplVwhaiAvPR9oPio8/U= X-Received: by 2002:a2e:964d:0:b0:25a:8dd5:cf04 with SMTP id z13-20020a2e964d000000b0025a8dd5cf04mr1122113ljh.278.1655927652636; Wed, 22 Jun 2022 12:54:12 -0700 (PDT) MIME-Version: 1.0 References: <25bdaf9d-fe54-48c9-d1a8-4a88325253c6@bitsnbites.eu> In-Reply-To: <25bdaf9d-fe54-48c9-d1a8-4a88325253c6@bitsnbites.eu> From: Andrew Pinski Date: Wed, 22 Jun 2022 12:53:59 -0700 Message-ID: Subject: Re: [MRISC32] Not getting scaled index addressing in loops To: m@bitsnbites.eu Cc: GCC Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: Wed, 22 Jun 2022 19:54:17 -0000 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 > > Does anyone have any hints about what could be wrong and where I should > start looking? > > Regards, > > Marcus >