From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 46DBE3858D1E for ; Sun, 9 Apr 2023 01:15:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 46DBE3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62e.google.com with SMTP id q2so6834921pll.7 for ; Sat, 08 Apr 2023 18:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681002910; x=1683594910; 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=JoBccdfn25m3mjI/bfD97LDxjqliHbUQ2Y/V1RWYB6Y=; b=eQHHAOgzYxHxLHV2a/QpNtK1B9xdka1rKeMmgV8UVPtRANBH9fcsK+9YjPi7E4n7Jk nb3ydCxGxnoeWdoT9/BVlyH+7Muh7DD25N1cmp02euh4AhoAdNfbV9wc4p8DrWozYs1G hG0f1+/+QRLece6dx5rs/rk08+9jO1AvueGraHcZxs46ePqwgdo8JYfN868AeUeaVrsH j82nHuK7d6Xp221jLwbovz2/HJqwTCJpN8o+c5iyCjuy2+5cXvz6D0939DrtnAQkACvu GBl8Q9e8RX+Zfr2lH3infsz9DeuLDhA3bhGirp9d1buv/O3bn2AQbHa2Ckrvk1uHSpwQ byvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681002910; x=1683594910; 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=JoBccdfn25m3mjI/bfD97LDxjqliHbUQ2Y/V1RWYB6Y=; b=HbhWUAlz3H/JsKANfcZzPVGtAiCBO/fBa4CPcTzei79S3vN6sRf+6X1IF1sh2u4TXL XXOMxCne+6p1CqsQ7K1S61JnRrwlf9IFOWQF+2qoiRRSS0KQQH08CJl/N9CuAqhnhl4+ L59C6I21PAjH13u9/kOGXfDctFSkiCRkyPzzyBM28JH5qOPeN/wDry7YI0ZV8tfYjjTB up0BPbsEh4RjBQ5++vvDQW5LfuUlXTzQFHMW/Dz3zuKgc+ZNiYim9rt1YD6bbZKNCGrK /xeIUtiAsBvi/2yXs1O0PM1R0Dje5NSFkXdGaM6lKpqpZsB5DKusV1FfJK+WfdDFy9W+ lj1Q== X-Gm-Message-State: AAQBX9c7U6+zhrWinKhcGPS4urv3C3HHqxbwfdUj2ghs1rLXH1Qfslia AqQ3Yh4KFpVp80KBEEzRTJs= X-Google-Smtp-Source: AKy350blbdNwUxM4CWn3/BBBCA3yUUsE7MASytffSSYsko9UFP1YWU/XJRzbLoK0ljsXSLviObRFMg== X-Received: by 2002:a17:90b:4a0e:b0:246:82ac:b6b2 with SMTP id kk14-20020a17090b4a0e00b0024682acb6b2mr2906633pjb.9.1681002909868; Sat, 08 Apr 2023 18:15:09 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id ay5-20020a1709028b8500b00198d7b52eefsm5050190plb.257.2023.04.08.18.15.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Apr 2023 18:15:09 -0700 (PDT) Message-ID: <1b51fda9-b942-bb7f-6406-9ac14a29940c@gmail.com> Date: Sat, 8 Apr 2023 19:15:08 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] combine: Fix simplify_comparison AND handling for WORD_REGISTER_OPERATIONS targets [PR109040] Content-Language: en-US To: Jakub Jelinek , Eric Botcazou Cc: Richard Biener , Richard Sandiford , gcc-patches@gcc.gnu.org References: <2876279.e9J7NaK4W3@fomalhaut> <2220543.iZASKD2KPV@fomalhaut> From: Jeff Law In-Reply-To: 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,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 4/6/23 05:37, Jakub Jelinek wrote: > On Thu, Apr 06, 2023 at 12:51:20PM +0200, Eric Botcazou wrote: >>> If we want to fix it in the combiner, I think the fix would be following. >>> The optimization is about >>> (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c)) >>> and IMHO we can only optimize it into >>> (subreg:SI (and:HI (reg:HI xxx) (const_int 0x84c)) 0) >>> if we know that the upper bits of the REG are zeros. >> >> The reasoning is that, for WORD_REGISTER_OPERATIONS, the subword AND operation >> is done on the full word register, in other words that it's in effect: >> >> (subreg:SI (and:SI (reg:SI xxx) (const_int 0x84c)) 0) >> >> that is equivalent to the initial RTL so correct for WORD_REGISTER_OPERATIONS. > > If the > (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c)) > to > (subreg:SI (and:HI (reg:HI xxx) (const_int 0x84c)) 0) I think it is. In both cases the AND wipes the upper 16 bits. > not really sure what for WORD_REGISTER_OPERATIONS > means AND with a constant which has the most significant bit set for the > upper bits. That's a very good question. I'm not sure either. Obviously in the non-constant case all the bits up to word_mode get used. The same thing is going to happen in the constant case. THe fact that constants are sign extended from the mode bit is a gcc-ism though and not necessarily indicative of what hardware is going to to. >> >> What happens if you disable the step I mentioned (patchlet attached)? > > That patch doesn't change anything at all on the testcase, it is still > miscompiled. That may be an artifact of later code in combine coming along and mucking things up in a manner similar. That what I saw after twiddling simplify_binary_operation_1. See simplify_and_const_int_1 and its calls to nonzero_bits jeff