From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by sourceware.org (Postfix) with ESMTPS id AFEF23858CDB for ; Mon, 5 Feb 2024 04:58:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AFEF23858CDB 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 AFEF23858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::d34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707109120; cv=none; b=dTB37CJ8/PXIZFy46YasNVXfkHEF51oyOmvw7IYRC5V4DU9U6C7AqWT3AyTHwzGuTVJqa4CKTvRPZHGEwW0PMDigzamywMOMv3u6vRCL1jVzcEEW6vw8mDAzMEU5Gga85VKsRbt7oj438bvNL/is8iIGAqMU3M6VpWpZBQGXcg0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707109120; c=relaxed/simple; bh=TgaaAf7FxN1DfzdwH9O8MWqdPOKH70NgloxjoB16ADw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=g+yg1QlwSH7grzeAeayewYysLAHmgqAFRGDod4OEN118B3Y0cqfEBvi+7CRIpDz1MQFyU9Ca0viFSXCyAwz/FY/ki47DBEGvUMpkOin1xdmt637/WDjLYxnsbXBLFO1mymnXb77GN+VHCsL2KjmI4LeQUxKVlLktw3/4QZfEzEQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-io1-xd34.google.com with SMTP id ca18e2360f4ac-7c029beb8efso51760039f.0 for ; Sun, 04 Feb 2024 20:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707109116; x=1707713916; 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=IfDtQcDQRlqp6UC24qwFHrbZ+vTbmMGxa9jVx5oa/Ts=; b=HSGpIYIzMF8EHeaAY4SacREW2S6Do0Xxca13m6KipWeVrrxcHf/yfQ7ZqLYGTy3LUP 2H7N1a5nyujuBIMiwEdItVuJoSG6+ZwUXupkwsp+GtfX/D7gioZk2bMJJDizhjhH+6CS HDBAdH4iM4FCqnOYo5HHGrS3W2gwWe/RKP50wOMqU53vSzLgHvm06ualEDkGB/yJs6wv SQOQaBvIdI3EoY4+ze8nGCti4nsAOD0Jbk7WuL+hRoGeyKNwtXzcfo8MB6s9fx0ZUFrb vD6tKTLJv02dN4SWMRlckGNhY5wbnAwNN6O6DbRjQRdxRiq4DKE383X2lG+vMDT/H+g6 KGHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707109116; x=1707713916; 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=IfDtQcDQRlqp6UC24qwFHrbZ+vTbmMGxa9jVx5oa/Ts=; b=R6bkSC6902tZRd3Dk23rTqEowt1vg32tb3CMA8bM7K0UV6cQCiJou8NH1R4+dzgFEw 20k3MbsA5ethKXM/K2xIRx7e48+uO6HEdHWcjudbMCrVd+zl7sLnEO5ZiYHiLUf6fH0j Fck3gOxUT0EdazmBqfeY9PcufSfz8YCh0G3s5quaBd6JZlBrV0GsAxjP/mGpM+ZuX0MD XGDmXwCHrIa8yW96kG+UvrYfuUXd2lYNP2EMCOJVhSNOFDFxSdKyEz2Esn6/92CWOloB oG0dye+GmlntTkRApRRu4PUaAwTxeVuzcPPAPkhpZ27iwV4x1Cj/3/5qmYx8OrCM5drD FHPg== X-Gm-Message-State: AOJu0YzX6ROgD2KXE8069F6pFMb0PWuqqK8KOpiVXnRbHq2lZW8KU5NJ 2l9X6CKb1/60Jik2V96UvEEu55eCHD5LfLQNKA43VZqJ3AgRQfNo X-Google-Smtp-Source: AGHT+IEXXdGcOhOZyyd04Ylxs+uD04gwvLCqZIJjL7fylhBuCJbl4/cyf4iufCrxRQTLJxOEwaQ0Hw== X-Received: by 2002:a05:6602:447:b0:7c2:ce25:a210 with SMTP id e7-20020a056602044700b007c2ce25a210mr3984660iov.9.1707109116523; Sun, 04 Feb 2024 20:58:36 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUCxK/up6WC1oVBBorjDlr5iLEAoph3kQjNS3ndI7r6d8cVTWduj3mpgFMyzgGMHktJ5DyHG96/Z5TkP/WE6RcjPgnqtBhNTR+Uog== Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id g7-20020a056602072700b007bf197d6ca8sm1898460iox.25.2024.02.04.20.58.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Feb 2024 20:58:36 -0800 (PST) Message-ID: <5c564b6d-b74e-4648-a4bd-cc70724863d2@gmail.com> Date: Sun, 4 Feb 2024 21:58:34 -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> <3f212170-f555-4f78-aff9-2ebdb8d4cc78@rivosinc.com> From: Jeff Law In-Reply-To: <3f212170-f555-4f78-aff9-2ebdb8d4cc78@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/2/24 15:48, Greg McGary wrote: > On 2/1/24 10:24 PM, Jeff Law wrote: >> >> On 2/1/24 18:24, Greg McGary wrote: >> >>> 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. > > input: (sign_extend:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86] > ) [1 minus_1+0 S4 A32])) > > result: (subreg:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86] > ) [1 minus_1+0 S4 A32]) 0) > > Later, the high part of the PSoM statically evaluates to 0, the code to > load and test is elided, and the incorrect alternative is emitted > unconditionally. So I think we need to know where that high part gets statically turned into a zero. I'm not happy with the sign_extend->subreg transformation as we generally want to avoid (subreg (mem)) for various reasons. So we'll probably want to do something like your patch as well. But let's chase down the static evaluation of the high part to zero first -- that's clearly wrong given the defined semantics of (subreg (mem)) in the presence of LOAD_EXTEND_OP. jeff