From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id D29F53858D28 for ; Tue, 23 Nov 2021 20:14:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D29F53858D28 Received: by mail-pg1-x536.google.com with SMTP id l190so107296pge.7 for ; Tue, 23 Nov 2021 12:14:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=CkbwYlv+fQnz8EsDL1Qz0yHvR2u5IZ+ptW0GLCL8grQ=; b=dlsjr9VEdx8wEv3MWsI4PBoVGVW1Pp9G0m00UjBLjAwWqbtgSTb8nTZIPhfP9OrELA aJ91cYVMGZvgiT+yN68HbrkAMI+coajKid6Zc0OzPDjByCvOzy4mFV0Dqz4GYl4SXxn4 AHET2xiVo0aJyQpH4VJ06XNa0cRA8iVZJgQyCvanz0mfFTmhL5jEhcaVS+R/NTYcBmQ9 BjZfQ1chYa776Pw2rKHVVVCFW6GUk56vFHiW5ctx2Tvesm/d6k08TaBIqN1R0Pf4M3ip SG+zISznPI9iNECH+7QkoSBTgwjo/IX9uwA6ybRLSQKjqj3C522IF4eKr7ZKjlQxBeVU MYDg== X-Gm-Message-State: AOAM532m/fvpylTr5ipAZWPzu+4XLFtGxKzf6h98h1V9iHHIIgE6iCZM 581exMwSpvzXByOZ0Nr3rd4= X-Google-Smtp-Source: ABdhPJzdq/RPwd78i85Iwc2yxJxfS0JFi3zxqXBohAmkqNXqocj61u8A5hbFanQIyRRIVmkzLmBx+A== X-Received: by 2002:a63:1446:: with SMTP id 6mr5675056pgu.150.1637698471695; Tue, 23 Nov 2021 12:14:31 -0800 (PST) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id z93sm1973798pjj.7.2021.11.23.12.14.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Nov 2021 12:14:31 -0800 (PST) Message-ID: Date: Tue, 23 Nov 2021 13:14:30 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [EXTERNAL] Re: [PATCH][WIP] PR tree-optimization/101808 Boolean comparison simplification Content-Language: en-US To: Navid Rahimi , Navid Rahimi via Gcc-patches References: <0320449b-433b-1e27-732f-4fd3e17b76b6@gmail.com> <8b28f52d-2e2a-7e73-f0c5-3ab6289f430a@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=-4.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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 20:14:34 -0000 On 11/23/2021 1:08 PM, Navid Rahimi wrote: >> In gimple your primary goal should be to reduce the number of >> expressions that are evaluated. This patch does the opposite. > That is actually a really good point in my opinion. I am hesitant about this patch and wanted to hear gcc-patch opinion about this. Doing something like this in IR level is a little bit counter intuitive to me. I will take a look at LLVM in my spare time to see where they are transferring that pattern and what was the rationale behind it. It could be easily looked at as target expansion issue.  ie, there's two equivalent forms for the full expression and the desired form varies based on some property of the target.  The idea we've kicked around, but not implemented, would be to allow target specific match.pd patterns to drive rewriting expressions at the gimple->rtl border. Jeff