From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [185.56.85.156]) by sourceware.org (Postfix) with ESMTPS id C32BB385741D for ; Tue, 3 May 2022 02:10:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C32BB385741D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tantosonline.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=tantosonline.com Received: from 107.112.208.35.bc.googleusercontent.com ([35.208.112.107] helo=siteground277.com) by se28.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1nlhzu-0009Hx-Fe for gcc@gcc.gnu.org; Mon, 02 May 2022 21:10:44 -0500 Received: from [73.169.135.95] (port=48192 helo=kakukkfu.lan) by siteground277.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.90-.1) (envelope-from ) id 1nlhzu-000Btn-3w for gcc@gcc.gnu.org; Tue, 03 May 2022 02:10:42 +0000 Received: from dell-laptop.lan (router.lan [192.168.139.254]) by kakukkfu.lan (Postfix) with ESMTPSA id 5C525241 for ; Mon, 2 May 2022 19:10:41 -0700 (PDT) Message-ID: <0f574adfe4c15da62238eeba1c939414a4a23198.camel@tantosonline.com> Subject: Multiple types of load/store: how to create .md rules? From: Andras Tantos To: gcc@gcc.gnu.org Date: Mon, 02 May 2022 19:10:41 -0700 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - siteground277.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tantosonline.com X-Source: X-Source-Args: X-Source-Dir: X-Originating-IP: 35.208.112.107 X-SpamExperts-Domain: siteground277.com X-SpamExperts-Username: 35.208.112.107 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.112.107@siteground277.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.19) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT811QMC66mQjOmDMsFmQKNCPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5xBytxzJBgOlCIhBVn7zf5DAxQ+GhOWeJSm0X/4oD2rzaZg NL8xGKU/ob23ZmqR5kQh55uqY3MhMgFAHq5BxPxPnSWXEV458bUmxaOKcxICtcN9X9K1DzVKciEj mqsTuLPQAKujagVaTNLZ5X+kLHvN+ufcSwqqOlrljbZrM+IOzcdMIqsIyb3aJqs33ZX4HJh0xl54 MAEbe1oNTNeaZ2bNJnWeeuYTXKpbWwq0Jmmi2jy7s4USXZaJQ5anTiXvwhuPi0A2vLwcNEjxGjiC Erd+CaH1pXLWuTQvZs3R7y15yIzIacMilJyGVyjpEgOg2D9z7iXziAEKWBLXmO85pBwPaF+P3CGL wqkaQ0xpotL0Mhypt3L7tZhLu6Os9ceqGjHQelPdLZIWapW8lSgOkuDXqHh92LXjpWxyqA19gVEn 1I8jz3K25BQZYLiRBulvflK9x7G+8oFGjk5+Tb1j8PJET4ztkOffVWdpRr+g5kzHCGrLhMVo7s5r C/i1xA6nwvG8Ksk+aedMfNWSnJswrtlNQ8clfdequDnRZkTy+cnx+wzevvA7ArqeQFEd2navgAmn OvL8Z8nObfEzCxRgiDMmm7RVhDC6rGajPOQMsilQygZImPb9UZXs+o5qEZeRpTi3BT/xcase7lCw 0EQdzS0Qs10w7kA+lqPr+8hLk2VakZuPHTGy57z4DEVRIdl9VBF/invNmcNqM/r7U1ExcrbA4G/y b0lqja52Mvsrgj8rEk7tj7p+dyFIQ47gnxHR/cQeFcyQ7VJExC7Q4eRzWD0n0z6bhalFEM/pjPCQ A+BAlkOpG56vNwNAHsDD96cr7LsGGzgmrxJJssXyURBEIIDYJMPEAAC5mJVNKOXqIK/gaPRhAApx liweziBay70pyOaVQ86ionyaSmLAxFsa3+YUPAlbDjazCbhs7qBpykynMvte84F69yef3rjIE9aq rvwwVFFEq45gMHpOzZY5w3lZONZwysYcuEaP1yUDhIrf6APNx91A6n31AAHEln911CjeNHk15Vol AGHS5rCXQKDywZSW8C3uaBiKZzYl7/DyqzzEOtOWX+ZTSN4+SxiH2XbbksYLroyN1JYjH3L7qaaK PM3kr7e7CDjX3ZthNfMWi+djXZBNOJeqVzGgrKtR6HA= X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, MEDICAL_SUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 03 May 2022 02:10:46 -0000 All, Thanks for all the help from the past. I'm (still) working on porting GCC to a new processor ISA and ran into the following problem: the CPU supports two kinds of register+offset based loads (and stores). The generic format accepts any base register and any offset. The syntax for this type of operation is: $rX <- mem[$rB + ] For code compatness reasons, there's another (shorter) form, that accepts only $sp and $fp (the stack and frame pointers) as base registers, and an offset in the range of -256 and 252. Finally this form inly supports a transfer size of 32-bits. The syntax for this format is: $rX <- mem[tiny $rB + ] I would like to coerce GCC into using the 'tiny' form, whenever it can. In order to do that, I've created a new predicate: (define_predicate "brew_tiny_memory_operand" (and (match_operand 0 "memory_operand") (match_test "MEM_P(op) && brew_legitimate_tiny_address_p(XEXP(op, 0))" ) ) ) The function referenced in the predicate is as follows: static bool brew_reg_ok_for_tiny_base_p(const_rtx reg) { int regno = REGNO(reg); return regno == BREW_REG_FP || regno == BREW_REG_SP || regno == BREW_QFP || regno == BREW_QAP; } bool brew_legitimate_tiny_address_p(rtx x) { if ( GET_CODE(x) == PLUS && REG_P(XEXP(x, 0)) && brew_reg_ok_for_tiny_base_p(XEXP(x, 0)) && CONST_INT_P(XEXP(x, 1)) && IN_RANGE(INTVAL(XEXP(x, 1)), -256, 252) && (INTVAL(XEXP(x,1)) & 3) == 0 ) return true; return false; } Finally, I've created rules for the use of these new predicates: (define_expand "movsi" [(set (match_operand:SI 0 "general_operand" "") (match_operand:SI 1 "general_operand" "") )] "" " { if (!(reload_in_progress || reload_completed)) { if(MEM_P(operands[0])) { // For stores, force the second arg. into a register operands[1] = force_reg(SImode, operands[1]); // We should make sure that the address // generated for the store is based on a // + pattern if(MEM_P(XEXP(operands[0], 0))) operands[0] = gen_rtx_MEM( SImode, force_reg(SImode, XEXP(operands[0], 0)) ); } else if(MEM_P(operands[1])) { // We should make sure that the address // generated for the load is based on a // + pattern if(MEM_P(XEXP (operands[1], 0))) operands[1] = gen_rtx_MEM( SImode, force_reg(SImode, XEXP(operands[1], 0)) ); } } }") (define_insn "*movsi_tiny_store" [(set (match_operand:SI 0 "brew_tiny_memory_operand" "=m") (match_operand:SI 1 "register_operand" "r") )] "" "mem[tiny %0] <- %1" [(set_attr "length" "2")] ) (define_insn "*movsi_tiny_load" [(set (match_operand:SI 0 "register_operand" "=r") (match_operand:SI 1 "brew_tiny_memory_operand" "m") )] "" "%0 <- mem[tiny %1]" [(set_attr "length" "2")] ) (define_insn "*movsi_general" [(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r,r,m,r") (match_operand:SI 1 "general_operand" "N,L,i,r,r,m") )] "" "@ %0 <- tiny %1 %0 <- short %1 %0 <- %1 %0 <- %1 mem[%0] <- %1 %0 <- mem[%1]" [(set_attr "length" "2,4,6,2,6,6")] ) When I tested this code, I've noticed a funny thing: the function prologs and epilogs seem to use the 'tiny' versions of loads/stores just fine. However (I think) some of the spills/reloads for local variables end up using the extended version. Even more surprising is that this behavior only manifests itself during optimized (-Os, -O1, -O2) compilation. It seems that -O0 is free from this problem. Here's one example: .file "dtoa.c" .text .global __udivsi3 .p2align 1 .global quorem .type quorem, @function quorem: mem[tiny $sp + -4] <- $fp ########### <------- OK mem[tiny $sp + -8] <- $lr mem[tiny $sp + -12] <- $r8 mem[tiny $sp + -16] <- $r9 mem[tiny $sp + -20] <- $r10 mem[tiny $sp + -24] <- $r11 $fp <- $sp $sp <- short $sp - 48 $r9 <- $a0 $r8 <- mem[$a1 + 16] $r0 <- mem[$a0 + 16] if signed $r0 < $r8 $pc <- .L7 $r8 <- tiny $r8 + -1 $r0 <- tiny 2 $r0 <- $r8 << $r0 $r10 <- short $a0 + 20 $r1 <- $r10 + $r0 mem[$fp + -32] <- $r1 ############## <-------- should be 'tiny' $r11 <- mem[$r1] To a previous problem I've asked, Andrew Pinski replied that I should merge all *movsi patterns into a single one to avoid (in that case) strange deletions in the generated assembly. Is that possible here? It appears to me that I would need the ability to differentiate the different patterns using constraints, but is there a way to define custom versions of the 'm' pattern? I didn't find anything on that in the documentation. Did I miss something? Thanks a bunch, Andras