From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 8AC503856092 for ; Tue, 18 Jul 2023 23:42:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8AC503856092 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-666e6ecb52dso4076205b3a.2 for ; Tue, 18 Jul 2023 16:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1689723741; x=1690328541; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=Cc7nacIRwyAqAfbm2rMmkGd9VOeARRE5F+HFv2pz/To=; b=i7o+d0eLQQ3B6EICJITbYC7h/n80YuQsvwLPm+VIBO4Q6P+ATghktdKgT0Utlrrqk3 jwfeIJxK1D07dqEhniIXd4AtzoNvJ8tqq3j6DqpWG0bh/kSNmyFw9kyIGO4w4gy+ejE8 SDqyvc22fiYtgRVjY9nVrYLxuiAvenoRD9M5m1evMSFvIC0HdhtloMZKk4ImS1x+lruJ SZnMwPUWvPk+y93ZMO6R6BSU7m+Z0aKCZ1G0CYnSBnvu+nVZUECxozSQaQVzXg1t9yxN FvY5M6kTVsVPtiD10VAFyXTdd+Swb+gfCEN6Ue4S2DVN3iGJd7tw9+ss3KPcYK16Ze3w i5kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689723741; x=1690328541; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Cc7nacIRwyAqAfbm2rMmkGd9VOeARRE5F+HFv2pz/To=; b=QfnHmjUhe00kSCgBWIdQNojQVQF8MluHTOZq1GggYG7itGCnZPOtc2Dtdm+RJTFYYg vqYZnXTky/jrhiO4GSkWSxZFZLBZv89hN2gV12oaHlvFAuzLASUquxigekdY+jHObPb+ yKNrYDPlXof4jhZOVqGSPM94JPtHUbPmFOaOcu54UxJ0LtH7dA59AddJ6GIpQIM8TjG2 zzFyopDOd9XHe9eO2LVkPMQj2aYJDpVQBD2ug8LGJFu4bz9Na6zwQtSCXEMKx7to4f3N DuZQXAXWWZ6KEcdhYEAGsjO4zOAmUNwbPqhlxeFEmdWU9N/EFGM1cmXnpI1YloAueFER 2OPA== X-Gm-Message-State: ABy/qLYI07GCb+9qIGyH/tWvfDUyn5JJhq2UmBUXjbZ4o9zYTboFnYQk NYnumjBr2Q7+pBNrOtn167jMFg== X-Google-Smtp-Source: APBJJlGhQ2HD7N1XgYSpR0VL5p2DB/wj3TUyVhJQ7/vYZxaVD6F6+m69FFaEBR8kcGJO6j+KvBou/A== X-Received: by 2002:a05:6a20:728b:b0:129:3bb4:77f1 with SMTP id o11-20020a056a20728b00b001293bb477f1mr15506556pzk.0.1689723740694; Tue, 18 Jul 2023 16:42:20 -0700 (PDT) Received: from [10.0.16.165] ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id l6-20020a170902f68600b001b89045ff03sm2403441plg.233.2023.07.18.16.42.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jul 2023 16:42:20 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------eDQ1zt0f45WR5mvEY7axVKFU" Message-ID: <59f02830-eae9-6a52-dd63-48a7217905ef@rivosinc.com> Date: Tue, 18 Jul 2023 16:42:19 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets. Content-Language: en-US To: Jeff Law , Manolis Tsamis Cc: gcc-patches@gcc.gnu.org, Philipp Tomsich , Richard Biener , Jakub Jelinek , gnu-toolchain References: <20230713141336.3950751-1-manolis.tsamis@vrull.eu> <1420ed26-9c30-b09e-f45c-54c89516814e@gmail.com> From: Vineet Gupta In-Reply-To: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SCC_5_SHORT_WORD_LINES,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------eDQ1zt0f45WR5mvEY7axVKFU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Manolis, On 7/18/23 11:01, Jeff Law via Gcc-patches wrote: > Vineet @ Rivos has indicated he stumbled across an ICE with the V3 > code.  Hopefully he'll get a testcase for that extracted shortly. Yeah, I was trying to build SPEC2017 with this patch and ran into ICE for several of them with -Ofast build: The reduced test from 455.nab is attached here. The issue happens with v2 as well, so not something introduced by v3. There's ICE in cprop_hardreg which immediately follows f-m-o. The protagonist is ins 93 which starts off in combine as a simple set of a DF 0. | sff.i.288r.combine:(insn 93 337 94 8 (set (reg/v:DF 236 [ e ]) | sff.i.288r.combine- (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190 {*movdf_hardfloat_rv64} Subsequently reload transforms it into SP + offset | sff.i.303r.reload:(insn 93 337 94 9 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp) | sff.i.303r.reload- (const_int 8 [0x8])) [4 %sfp+-8 S8 A64]) | sff.i.303r.reload- (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190 {*movdf_hardfloat_rv64} | sff.i.303r.reload- (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0]) It gets processed by f-m-o and lands in cprop_hardreg, where it triggers ICE. | (insn 93 337 523 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp) |                 (const_int 8 [0x8])) [4 %sfp+-8 S8 A64]) |         (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 -1 ^^^ |      (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0]) |        (nil))) | during RTL pass: cprop_hardreg Here's my analysis: f-m-o: do_check_validity() -> insn_invalid_p() tries to recog() a modified version of insn 93 (actually there is no change, so perhaps something we can optimize later). The corresponding md pattern movdf_hardfloat_rv64 no longer matches since it expects REG_P for operand0, while reload has converted it into SP + offset. f-m-o then does the right thing by invalidating INSN_CODE=-1 for a subsequent recog() to work correctly. But it seems this -1 lingers into the next pass, and trips up copyprop_hardreg_forward_1() -> extract_constrain_insn() So I don't know what the right fix here should be. In a run with -fno-fold-mem-offsets, the same insn 93 is successfully grok'ed by cprop_hardreg, | (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp) |                (const_int 8 [0x8])) [4 %sfp+-8 S8 A64]) |        (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190 {*movdf_hardfloat_rv64} ^^^^^^^^^^^^^^^ |     (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0]) |        (nil))) P.S. I wonder if it is a good idea in general to call recog() post reload since the insn could be changed sufficiently to no longer match the md patterns. Of course I don't know the answer. P.S.2 When debugging code, I noticed a minor annoyance in the patch with the whole fold_mem_offsets_driver() switch-case indirection. It doesn't seem to be serving any purpose, and we could simply call corresponding do_* routines in execute () itself. Thx, -Vineet --------------eDQ1zt0f45WR5mvEY7axVKFU Content-Type: text/plain; charset=UTF-8; name="sff.i" Content-Disposition: attachment; filename="sff.i" Content-Transfer-Encoding: base64 YSwgYywgZCwgZywgaCwgaSwgaiwgaywgbSwgcCwgcSwgciwgYWEsIHQsIHUsIHg7CmRvdWJs ZSAqZiwgKnM7CmRvdWJsZSBsLCBuLCBvLCB2LCB3OwpiKCkgewogIGRvdWJsZSBlLCBhZCwg YWUsIGFmLCBhZywgYWgsIGFpLCBhaiwgYW0sIGFuLCBhcCwgYXEsIGFyLCBhcywgYXQsIGF2 LCBhdzsKICBmb3IgKDsgcTsgcSA9IGFhKSB7CiAgICByID0gZlt4XTsKICAgIGFoID0gZlty ICsgMl0gLSBnOwogICAgYWYgPSBmWzBdIC0gZltyXTsKICAgIGFnID0gMSAtIGZbciArIDFd OwogICAgYXYgPSBhZSAqIGFmICogYWggKiBhaTsKICAgIGFqID0gaCAtIHcgKiBwICogYWg7 CiAgICBhbSA9IG8gKyBhdiAqIGFmOwogICAgYW4gPSBqICogbyAqIGF2ICogYWc7CiAgICBh cCA9IChhbSAtIG0pICogYWQgKiAoayAtIGFuIC0gbikgKiBhIC0gdiAqIGM7CiAgICBhciA9 IChhaiAtIGwpICogYzsKICAgIGlmIChhKQogICAgICA7CiAgICBlbHNlCiAgICBhejoKICAg ICAgc3dpdGNoIChkKSB7CiAgICAgIGNhc2UgMToKICAgICAgICBlID0gYXcgKiBpOwogICAg ICAgIGJyZWFrOwogICAgICBjYXNlIDI6CiAgICAgICAgZXhpdCgxKTsKICAgICAgfQogICAg c1swXSA9IGFwOwogICAgdCArPSBhdCAqIGFxOwogICAgdSA9IGFzICs9IGF0ICogYXI7CiAg ICBpZiAoYykKICAgICAgZ290byBhejsKICB9CiAgcmV0dXJuIGU7Cn0K --------------eDQ1zt0f45WR5mvEY7axVKFU--