From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 592923858D35 for ; Thu, 3 Aug 2023 15:21:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 592923858D35 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-x62b.google.com with SMTP id d9443c01a7336-1bba2318546so9470705ad.1 for ; Thu, 03 Aug 2023 08:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691076066; x=1691680866; 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=9K89Rm6Yy7dTDx4siUWIYUc+QwYY4m4HKzw/7AuJfaI=; b=KQd8jxUj2AB5wxGtXSYI6FqNtM+E1z7HvPkmZmlc1wBqIYDkbyXRJEVWWfdwCLwW+q B3B+QnRfxjdlpujU80s9aGrcgpNrqthVR+I4CmQVhwdcxMddVmdD0OajTUYZNEPkdfQS 2dIKoSar74mz2FkbhnzxPLaR5IJ6PA2W50P8x5UtezQc1gS0IN9DnvZovHxYvMVwW+Nv YI+BSLGg94RX4y6V98+Y4J88Hmo8mTZqTCG5MZ0l+N22rhqO5tw74TO9wjB6dm3vveak 4h/TuHxAQ6TNkizfKyhVOhm9VS6KnBivO6BagmktPDYWuHq9CbhXhGqMEFK4gIfoDLTQ XA1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691076066; x=1691680866; 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=9K89Rm6Yy7dTDx4siUWIYUc+QwYY4m4HKzw/7AuJfaI=; b=XeyL5lWHQeKOZar602Ainy6vQVwUVFmtkk1o0SgO4Nm9n+20BEw6CG8tHnyumkl16a 79fVYYfmMEFbPEqfHx9F1jWYQggzo2M04drhiIXJpshLZrsAIiDwYIGk/YGkAA/bQLsD a1h3wn0OWnYMDGwRG5kM/z2tmCYIpdX1mpFtqfcfxzJHqqCQNeuyFjB+awgG7Wa/uAPd o5WrtEcRj80itJas1noTLhRCHQQoacjqCatZzLk+qyDilqWLF2qiXs9HGe3DjNAVqUca 5ORhuxUlXP0mEV+XA5cGt+lCDh02C+5lIsE3IEjjtNGSMAH1TP5NqsEKdEEKYqHoFDCi adCw== X-Gm-Message-State: ABy/qLabTDWEbl4su15r5SSw3Gpp3gDpkQboYHukfBBXnlnJ4UD4JZM0 U3dxPucl+k4sEhZIlY3foq4= X-Google-Smtp-Source: APBJJlGsTT3NTWpLBPAOt4p70uGWP4YKFHLWTwKJyP3TD0/a3d9sahZcL++U1Cq84rUBmtEBHpAfmA== X-Received: by 2002:a17:902:7009:b0:1bc:2bd:8527 with SMTP id y9-20020a170902700900b001bc02bd8527mr15275290plk.42.1691076066085; Thu, 03 Aug 2023 08:21:06 -0700 (PDT) Received: from [172.31.1.103] ([172.58.35.95]) by smtp.gmail.com with ESMTPSA id jf1-20020a170903268100b001b85bb5fd77sm3219plb.119.2023.08.03.08.21.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Aug 2023 08:21:05 -0700 (PDT) Message-ID: <76e4d7a6-65af-7af3-2f33-d935cf628214@gmail.com> Date: Thu, 3 Aug 2023 09:21:03 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v1] [RFC] Improve folding for comparisons with zero in tree-ssa-forwprop. Content-Language: en-US To: Richard Biener , Manolis Tsamis Cc: Philipp Tomsich , Andrew MacLeod , gcc-patches@gcc.gnu.org References: <20230316152706.2214124-1-manolis.tsamis@vrull.eu> <8bd8b246-a252-0e05-414c-ab1e35975aea@gmail.com> 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.3 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 List-Id: On 8/3/23 01:04, Richard Biener wrote: > On Wed, Aug 2, 2023 at 4:08 PM Manolis Tsamis wrote: >> >> Hi all, >> >> I'm pinging to discuss again if we want to move this forward for GCC14. >> >> I did some testing again and I haven't been able to find obvious >> regressions, including testing the code from PR86270 and PR70359 that >> Richard mentioned. >> I still believe that zero can be considered a special case even for >> hardware that doesn't directly benefit in the comparison. >> For example it happens that the testcase from the commit compiles to >> one instruction less in x86: >> >> .LFB0: >> movl (%rdi), %eax >> leal 1(%rax), %edx >> movl %edx, (%rdi) >> testl %eax, %eax >> je .L4 >> ret >> .L4: >> jmp g >> >> vs >> >> .LFB0: >> movl (%rdi), %eax >> addl $1, %eax >> movl %eax, (%rdi) >> cmpl $1, %eax >> je .L4 >> ret >> .L4: >> xorl %eax, %eax >> jmp g >> >> (The xorl is not emitted when testl is used. LLVM uses testl but also >> does xor eax, eax :) ) >> Although this is accidental, I believe it also showcases that zero is >> a preferential value in various ways. >> >> I'm running benchmarks comparing the effects of this change and I'm >> also still looking for testcases that result in problematic >> regressions. >> Any feedback or other concerns about this are appreciated! > > My comment from Apr 24th still holds, IMO this is something for > instruction selection (aka the ISEL pass) or the out-of-SSA tweaks > we do during RTL expansion (see insert_backedge_copies) I'm still generally supportive of biasing to zero, but as Richi has noted the current implementation needs to be pushed further back into the pipeline, preferably all the way to isel or gimple->rtl expansion. Jeff