From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 5155B3858403 for ; Fri, 2 Feb 2024 14:40:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5155B3858403 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 5155B3858403 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706884815; cv=none; b=Q+4pXaN7q2nBttr3BIC8FF4tRD850jNm1C35VNqPDKs0Z7SyZkrOyxDuLwBteA2hqSqE2Di2WaLmGKKJHjbsd9qM4wUOGQ8fpZ/DFBBf5Tt9G3FoNsvt5rAu76pqbMQGSBWvQ4snPPjHokM/9vQGGZgolC/EHCQdkhK4QpMCaSA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706884815; c=relaxed/simple; bh=8LTrHZP/LQCCSSFo2zFfJ/VfmVjErOIbXZz3SfEtsxs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=q0YYyc4GfSsx6PLdfw1Cg3HwlgGzteFzLRashUM5LqZY3Zvf9b3ECynplFhNbl3bakfhvRXj9Cn/yTHmwgZHB9WchxLEBk+lVHHJNpModWvEI1vdiVBVd5lNz51vl+K/7cpJqN/wcivSd+0+sQnFJPcdHDiJbgUjITY7Ot3zfq4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-363afc38a1cso3326635ab.3 for ; Fri, 02 Feb 2024 06:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706884812; x=1707489612; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=tRreXhoPfzNpPNeaINwKR1J+9pxhftSuM8Bjty5rz1g=; b=G3duxcTgv4VBpzzXi7Lsqs5OiwaKm8gxaIhKUMRaYoh7BmR+36P120wBgRbGAP52vb VD7wuVx4WnE4wgH0kwW/u4s3CqHDKGub0+2Hy+2ECMdBP18DHVHVuy9thrjvcDNntqlm r1dQHJjB/BYdi7l6b4oEpyg1MMiwirYYl8f8ROn45/ycnmjixaxxKsfaFYPOAEcYmSHP 18a0PlmUsdihwQysSZdrZhInlm5iNpTLBlP7GQ83Pz9vWsT9Hn7Hz6b6QLMdH0T/eh8n a2eQJZSl5NIS+DoTcYdieU3pONn0nFROEXHDP9AnsPH6nsvVct5mOOugOAQ8ekuqQhXA sQhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706884812; x=1707489612; h=content-transfer-encoding:in-reply-to:from:references: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=tRreXhoPfzNpPNeaINwKR1J+9pxhftSuM8Bjty5rz1g=; b=RF8y+gnlEdiqu95c/ZS3cPUeHa9IYTpxKeLDCSFcmfyklhnt2Ts5dMceNJRBBzAfGj WQsU2yHXIk+Qh3T+sDw+AceOqROkIcNOLmppW/yq9gcEl+PBauV1/Q3rp69lpLpaMPcX icRVkQf5DUSDSM8wKI/ss2b+am2VKbJVANf+8JLBbpv4EqH45h3o7e94MWyj4HbJNp8f 8P6LO8Q5OHbLas8OTFOApbFWdTEcTe/rAro5pXa5MPHnQKCQ3Wp3F7VuCY7wnwBK3LVM daN3tzmtVki8U7YlWnScHQS3+iWxPz6P6uY50j7ncWCgejuWm/FOIThzw6JuOzUOuzcz iltw== X-Gm-Message-State: AOJu0Yyh1bLb4sS09l4ldaA7ZQ/gC0y0vsasGXzuaC8UPFWp6rJLPO+f 8NoopwHQZroF7A3P7wReUZDPZ7Oc+4ihxOOAHB4boh1a1GM/FI+yIvhUoizK X-Google-Smtp-Source: AGHT+IHpwly4QDGT8nMtDuKcXzI4zTjdGnedTUPqrZTbz8bQHSZ0+A49aiWASKA3EuGmi0UhnblaWg== X-Received: by 2002:a92:c5a3:0:b0:363:a471:f945 with SMTP id r3-20020a92c5a3000000b00363a471f945mr2036302ilt.7.1706884812400; Fri, 02 Feb 2024 06:40:12 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXIiXKouXGyP/qBiGTj+XyzlUxqfi8IoFVaO0IM0ohK7A6sILqbIhdQqSxHCgTbjjeE2wV9mnvCsbijzMnGRC+ocuPD+qHxew== Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id bt2-20020a056e02248200b00363829e97f9sm622062ilb.14.2024.02.02.06.40.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Feb 2024 06:40:11 -0800 (PST) Message-ID: <2bf60308-cb26-414c-a6e2-4acecf78a53f@gmail.com> Date: Fri, 2 Feb 2024 07:40:10 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] rtl-optimization/113255 - avoid re-associating REG_POINTER MINUS Content-Language: en-US To: Richard Biener , gcc-patches@gcc.gnu.org References: <20240201142121.B149B38582BB@sourceware.org> From: Jeff Law In-Reply-To: <20240201142121.B149B38582BB@sourceware.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 07:20, Richard Biener wrote: > The following avoids re-associating > > (minus:DI (reg/f:DI 119) > (minus:DI (reg/f:DI 120) > (reg/f:DI 114))) > > into > > (minus:DI (plus:DI (reg/f:DI 114) > (reg/f:DI 119)) > (reg/f:DI 120)) > > as that possibly confuses the REG_POINTER heuristics of RTL > alias analysis. This happens to miscompile the PRs testcase > during DSE which expands addresses via CSELIB which eventually > simplifies what it substituted to. The original code does > the innocent ptr - (ptr2 - ptr2'), bias a pointer by the > difference of two other pointers. > > -- > > This is what I propose for the PR for branches, I have not made much > progress with fixing the fallout on the RTL alias analysis change > on trunk, so this is the alternative if we decide to revert that. > > Bootstrapped and tested on x86_64-unknown-linux-gnu on the gcc-13 > branch, bootstrapped after reverting of the previous fix on > x86_64-unknown-linux-gnu on trunk, testing is still ongoing there. > > OK? Any preference for trunk? > > Thanks, > Richard. > > PR rtl-optimization/113255 > * simplify-rtx.cc (simplify_context::simplify_binary_operation_1): > Do not re-associate a MINUS with a REG_POINTER op0. Nasty little set of problems. I don't think we ever pondered that we could have multiple REGNO_POINTER_FLAG objects in the same expression, but clearly that can happen once you introduce a 3rd term in the expression. I don't mind avoiding the reassociation, but it feels like we're papering over problems in alias.cc. Conceptually it seems like if we have two objects with REG_POINTER set, then we can't know which one is the real base. So your patch in the PR wasn't that bad. Alternately, just stop using REG_POINTER for alias analysis? It looks fundamentally flawed to me in that context. In fact, one might argue that the only legitimate use would be to indicate to the target that we know a pointer points into an object. Some targets (the PA) need this because x + y is not the same as y + x when used as a memory address. If we wanted to be a bit more surgical, drop REG_POINTER from just the MINUS handling in alias.cc? Jeff