From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id EE2123858C5F for ; Fri, 2 Feb 2024 05:24:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EE2123858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EE2123858C5F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::102d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706851452; cv=none; b=RUdNAnjwUfgAfaOx6ZeowB1nuteR+Soi+n24xkQuQpTY+hJHGHUghrVk+b6Etk+JBvZywy7j17LmliMQa6/+sUo2Y+UedcQdmugrVywzcYBI8td175a/z5RCzAnX2BjW+ddrbpUoI+Lqmu5vKgYIJoa59mcWAxyg3+X2mhgkz9w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706851452; c=relaxed/simple; bh=gzwxl+4DjbgctZgODmjF1PNJBLLMqyGiAVKQord1S0E=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=wKho8uAypWQ6Ih9mCvxhXknq7TvFcz2wHtA+7FuvjeSoMqOKY7Euy4nBH1g4zmYSRUCB4G7BOO0uO/kGoA5GDOI6dC0g0vANZBTMQXRFy4LkU1KBNA79+t8WoGrWMdhYew1lMgjIUapIpjzqV0VNA4P1FMWEZvXZe4wm+OKxaEk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-290d59df3f0so1336238a91.2 for ; Thu, 01 Feb 2024 21:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706851447; x=1707456247; darn=gcc.gnu.org; h=content-transfer-encoding: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=AMcRlkDam1gvASHNMEw0Aq6CnFZ3By6h7gsVXb3dCLs=; b=NLsQsBPvkgoAQC/42g6/22nZcA4feCLUwN7IRzM+ONk+ZtMhXXQ5QYjySVthHyW9ry ifs3E1/T6nDZD/DlevJmjgMOFrwxKpNVGNSgmvjpHcmI6GHhR2V3YtaPt5v8PYTGX5be Bsm+uqAuVetrMH1Xjm7jwqVdqEBJSaP8fEcqIBJPuHUAJjvOpDAybsjawEKVOh39J/1w wtZF80sQKCot4CNFHEmiB9HBHzxZmSutfwwjKCcroTQtuQ5PHSu0cVobG+ZJqmMIbGXo pOoySJMVAKUdIhzO9knKy3jWvVa6iKayjpMg5ob8vTbw48L6pR0m9txMpbDHQe1zBR1r zekg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706851447; x=1707456247; h=content-transfer-encoding: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=AMcRlkDam1gvASHNMEw0Aq6CnFZ3By6h7gsVXb3dCLs=; b=BUAUlqUO+SeFKsTJN5UQhFmgi00O7oQa5WnGa+0GmmQzUBPZpr7xRL7/KqlxrvLrNI DC6Seosq8G1ApwLtt6/sabazb+wXia1M8/cBeGgd0roK30oiMl5lJs58B3SVvreKOoXk 2Q9eeoaRIqeiJ76y9L8iOULwvezfrSamDsD7B65M4bLXbVEzoRJsyEFs1BxUvP4dxT/z M8P2uoMZlq5vrcO9tTVbMo1htggQorSO4iro1LPL9a7oIy4jDtkfnd/YZd5de/nQzZ4n r3JY9My7SkMJUzPn+uB4eDlG10RkOQvr/eimwAUZzptA3+9wbLz9tsbDxBBmVQ3/ZoFz Jnow== X-Gm-Message-State: AOJu0YyMYT6PZO2FEhWvZQtOKZO1zPocua1IhfuQOZjQ7e4GcvltbnmF fw0fAwGe+Ft7nuPHWv0kdmkjG95B8E8vPiOEj5TjTEbxKnglT6oK X-Google-Smtp-Source: AGHT+IFzG31BE3jCxqTB3wHzHrrZ/CcYSYbGTBiPzdwkC7mG9EKi+zZxriqHIasUZ1VhhORSrLG1JQ== X-Received: by 2002:a17:90a:c68e:b0:296:2afe:25e with SMTP id n14-20020a17090ac68e00b002962afe025emr1315685pjt.32.1706851446724; Thu, 01 Feb 2024 21:24:06 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVGFFmu2u0QPMg07og9p7wMbyEgw0Fh0geDVVFxVd2CcpjKahJrkui26dgdHwqsqTN6NZXZPtHdUaPqdTkdZp4n197XvwtvDB1hXA== Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id q6-20020a17090a2e0600b00295d781cb1bsm4573027pjd.12.2024.02.01.21.24.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 21:24:06 -0800 (PST) Message-ID: Date: Thu, 1 Feb 2024 22:24:04 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010] Content-Language: en-US To: Greg McGary , Richard Biener Cc: gcc-patches@gcc.gnu.org References: <20240116221914.267015-1-gkm@rivosinc.com> <03b351a0-a5f4-48ab-bc67-765eabf5dbcd@rivosinc.com> From: Jeff Law In-Reply-To: <03b351a0-a5f4-48ab-bc67-765eabf5dbcd@rivosinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 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 List-Id: On 2/1/24 18:24, Greg McGary wrote: > On 1/18/24 9:24 AM, Jeff Law wrote: >> >> On 1/17/24 20:53, Greg McGary wrote: >>> >>> While the code comment is true, perhaps it obscures the primary intent, >>> which is recognition that the pattern (SIGN_EXTEND (mem ...) ) is >>> destined >>> to expand into a single memory-load instruction and no simplification is >>> possible, so why waste time with further analysis or transformation? >>> There >>> are plenty of other conditions that also short circuit to "do >>> nothing" and >>> this seems just as straightforward as those others. Efforts to catch >>> this >>> further downstream add gratuitous complexity. >> Because the real bug is likely still lurking, waiting for something >> else to trigger it. >> >> An early exit is fine when we're just trying to avoid unnecessary >> work, but there's something else going on here we need to understand >> first. > > > expand_compound_operation() wants to evaluate the sign- and > zero-extension of MEM. It begins by calling gen_lowpart(), which returns > the same result in both cases: a paradoxical subreg of a MEM (PSoM). > What is the value of the high part of a PSoM? Can that high part be > evaluated at compile time? Potentially, yes. If LOAD_EXTEND_OP returns ZERO_EXTEND, then we know at compile time those bits are zero. I could come up with ways to optimize the SIGN_EXTEND case as well, but that would require some state tracking and it doesn't immediately look like expand_compound_operation or its children use any of the state tracking that's available in combine. So for the sake of this problem, let's consider the SIGN_EXTEND case as not computable at compile-time in expand_compound_operation. > However, for a machine where (WORD_REGISTER_OPERATIONS && load_extend_op > (inner_mode) == SIGN_EXTEND), the high part of a PSoM is  only known at > runtime as 0s or 1s. That's the downstream bug. The fix for such > machines is either (A) forbid static evaluation of the high part of a > PSoM, or (B) forbid transforming (SIGN_EXTEND (MEM ...) ) into a PSoM. > My patch does B. Perhaps you prefer A? The trouble with A is that in the > zero-extend case, it is valid to statically evaluate as 0. It is only > the sign-extend case that isn't known until runtime. By the time we have > a PSoM, its upstream ancestor as sign- or zero-extend is already lost. > > Does that give you the understanding you desire, or are there deeper > mysteries to probe? It's a good start and I can see what you're trying to do -- and it may in fact be correct -- the quick discussion with Palmer Tuesday and your follow-up have helped a lot). But just to be sure, what's the incoming rtl at function entry? just "debug_rtx (x)" should be sufficient. jeff