From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id 73FD33858294 for ; Fri, 5 Aug 2022 16:12:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 73FD33858294 Received: by mail-pj1-x1036.google.com with SMTP id a8so3168277pjg.5 for ; Fri, 05 Aug 2022 09:12:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=du4pemkg8PtLIKaJ8zfyXPTmbdZbq49nC7BEoxItIPg=; b=3aZOASe4eFb1S6ev/1KAK2fNINU8/0j6iCrGNffUlhGVvUqSViKVvDY6Y0nM8lj7A6 2ObYbkFhaG8uyV29q3SFpiyjhdUUr3Pj0guJosoQ1D5F+2kNeJB0Ql6sJwEleKHdx6KU qkwHHceoi2McRytiCh3yo+QIHjKKwv9k+QWSkPuyq19sWoRSuqYwwW1m7JNcP31w0ZKj 6EyR8H+G1K3v2M0I2+aRRu7Cux2SvGijd+q7exoXy8j50P5bO70duxB0LxmNT295aFD4 OIoeMUv6U7RRD4nsMEmOprE6XJ3N/48AZ+EHua6Z013GT1NR0jRABR7JzXfBDo18Jp5Q l46w== X-Gm-Message-State: ACgBeo20su3j50hv4omf3ygB82UFaorrh8mqHP8XzQ8ayNSnszqGiywI 7eMwYZRW+QK42T7X8uQcvqd+Ja9fZGw= X-Google-Smtp-Source: AA6agR7BwR/XhHeFosEqnnyCx7bbqxYBe5DDgF+AASeebAeI9HcXHBde6Z0L3BCzf8UjR4JwacdMSw== X-Received: by 2002:a17:902:ce83:b0:16d:d667:d4df with SMTP id f3-20020a170902ce8300b0016dd667d4dfmr7274311plg.159.1659715941799; Fri, 05 Aug 2022 09:12:21 -0700 (PDT) Received: from [172.31.0.204] (c-73-98-188-51.hsd1.ut.comcast.net. [73.98.188.51]) by smtp.gmail.com with ESMTPSA id a5-20020a17090a008500b001f559e00473sm4129820pja.43.2022.08.05.09.12.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Aug 2022 09:12:20 -0700 (PDT) Message-ID: <9e29de32-8547-0f5d-553b-38d7f513613b@gmail.com> Date: Fri, 5 Aug 2022 10:12:19 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] lower-subreg, expr: Mitigate inefficiencies derived from "(clobber (reg X))" followed by "(set (subreg (reg X)) (...))" Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <7e3fe210-6dbc-fc29-dbb8-b951e89cf7e9@yahoo.co.jp> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2022 16:12:25 -0000 On 8/4/2022 3:49 AM, Richard Sandiford via Gcc-patches wrote: > >>> TBH I'm surprised we still run init_regs for LRA. I thought there was >>> a plan to stop doing that, but perhaps I misremember. >> Sorry I am not sure about the status of LRA... because the xtensa port is still using reload. > Ah, hadn't realised that. If you have time to work on it, it would be > really good to move over to LRA. There are plans to remove old reload. Definitely worth investigating.  With the cc0 removal done I think the last blocker for removing the old reload pass is gone.   We just need to get the remaining targets converted to LRA. > It might be that old reload *does* treat a pseudo clobber as a conflict. > I can't remember now. If so, then zeroing the register wouldn't be > too bad (for old reload only). No idea anymore either.  I'd be a bit surprised since IIRC the main purpose was to tell the old uninit warning code that the entire object was set by the subsequent libcall sequence.  But all that code is long-gone. Which I think raises a question.  Do we even need those CLOBBERSs anymore? > >> As conclusion, trying to tweak the common code side may have been a bit premature. >> I'll consider if I can deal with those issues on the side of the target-specific code. > It's likely to be at least partly a target-independent issue, so tweaking > the common code makes sense in principle. > > Does adding !HARD_REGISTER_P (x) to: > > /* Show the output dies here. This is necessary for SUBREGs > of pseudos since we cannot track their lifetimes correctly; > hard regs shouldn't appear here except as return values. */ > if (!reload_completed && !reload_in_progress > && REG_P (x) && !reg_overlap_mentioned_p (x, y)) > emit_clobber (x); > > in emit_move_complex_parts help? If so, I think we should do at > least that much. If we can't remove the CLOBBERs entirely, then this sounds like a good thing, even if it doesn't help this specific case. jeff