From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 9ECFC3947422 for ; Wed, 26 May 2021 16:59:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9ECFC3947422 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-584-bgqFPKQwP2aKg4xAFvlQnQ-1; Wed, 26 May 2021 12:59:34 -0400 X-MC-Unique: bgqFPKQwP2aKg4xAFvlQnQ-1 Received: by mail-qk1-f199.google.com with SMTP id z12-20020a05620a08ccb02902ea1e4a963dso1253986qkz.13 for ; Wed, 26 May 2021 09:59:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ZlGWOmc1a1sUIwNSpQN5RjJyE8e+L+KgFY8da1l4RaM=; b=bMj2yFIMuEkwzXdUaFyUAO/Yf5K5Z328MNKOROAgybttcYJcGJmjeRJexmWzyxZHji GyhwDrW4/3cEkRQW1YGndQayM+WboIuc3mjFh0REvO0R5+izY8V7EuSbXJj/kbd+MrCY hhF1O4FOSr6f380r7m+CoXh9vKFvur3DsYOumwjYPwjzLWsPoJoO5GHi6KNHhLuhO/fg OAjOMfPl0gGv6GsnmimZuU7lyj9kND1AB/92/Zz3e03CavGFeoXb9Tqvkm4MjX4wEu9h NTK3/lUX+NjV+rp3IgHY1qV5cm/LOQk96tlT+y0bZQ5f5Wal1ltL8LNvd2A11sgcaVs+ fgMA== X-Gm-Message-State: AOAM530I0z6TTL84Y3hbpu3cMJSM8Sjz3HLfsorRLk7vnwSM/m9MSKD7 z+sb5JDXON9U5PbmYiJ/lxIcG3DmsquDrTPyA+81gL+M9FgQ1CIq7yML5IybU3AFuF9toYsTjJ5 tMpWjtO0d82WsAbdETiyICPtBxtmEYodFAznDvQcJ9hlzysz8y+4y/u92FA0fNow47SFHvg== X-Received: by 2002:a05:620a:14b9:: with SMTP id x25mr39670006qkj.460.1622048373863; Wed, 26 May 2021 09:59:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJweN5GK5miS9UqUIHSZKYimh9faztqeYqZbzI4rfeKBuUYqkLGG3aXGq3uQQt1e7vG4gHP5VQ== X-Received: by 2002:a05:620a:14b9:: with SMTP id x25mr39669977qkj.460.1622048373543; Wed, 26 May 2021 09:59:33 -0700 (PDT) Received: from ?IPv6:2607:fea8:a25d:e700::2b5? ([2607:fea8:a25d:e700::2b5]) by smtp.gmail.com with ESMTPSA id t25sm1867200qkt.62.2021.05.26.09.59.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 May 2021 09:59:33 -0700 (PDT) Subject: Re: [PATCHv2] Add a couple of A?CST1:CST2 match and simplify optimizations To: Richard Biener , Andrew Pinski Cc: Bernd Edlinger , Andrew Pinski , GCC Patches References: <1621762863-26665-1-git-send-email-apinski@marvell.com> From: Andrew MacLeod Message-ID: <437e629c-9e59-fa4a-678c-1c7692bfe60a@redhat.com> Date: Wed, 26 May 2021 12:59:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-CA X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 26 May 2021 16:59:40 -0000 On 5/26/21 8:05 AM, Richard Biener wrote: > On Wed, May 26, 2021 at 1:37 PM Andrew Pinski wrote: >> On Wed, May 26, 2021 at 4:28 AM Richard Biener >> wrote: >>> On Wed, May 26, 2021 at 1:07 PM Andrew Pinski wrote: >>>> On Wed, May 26, 2021 at 2:01 AM Andrew Pinski wrote: >>>>> On Wed, May 26, 2021 at 1:43 AM Bernd Edlinger >>>>> wrote: >>>>>> On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote: >>>>>>> On Sun, May 23, 2021 at 12:03 PM apinski--- via Gcc-patches >>>>>>> wrote: >>>>>>>> From: Andrew Pinski >>>>>>>> >>>>>>>> Instead of some of the more manual optimizations inside phi-opt, >>>>>>>> it would be good idea to do a lot of the heavy lifting inside match >>>>>>>> and simplify instead. In the process, this moves the three simple >>>>>>>> A?CST1:CST2 (where CST1 or CST2 is zero) simplifications. >>>>>>>> >>>>>>>> OK? Boostrapped and tested on x86_64-linux-gnu with no regressions. >>>>>>>> >>>>>>>> Differences from V1: >>>>>>>> * Use bit_xor 1 instead of bit_not to fix the problem with boolean types >>>>>>>> which are not 1 bit precision. >>>>>>> OK. >>>>>>> >>>>>>> Thanks, >>>>>>> Richard. >>>>>>> >>>>>> Hmm, sorry, no luck. >>>>>> >>>>>> I think this caused: >>>>> If anything it is a bad interaction with changes between r12-1046 and >>>>> r12-1053; I am suspecting a bug in those changes rather than my >>>>> changes causing the bug. Debugging it right now. >>>> (gdb) p debug_tree(name) >>>> >>> type >>> size >>>> unit-size >>>> align:8 warn_if_not_align:0 symtab:0 alias-set -1 >>>> canonical-type 0x7ffff6b45b28 precision:1 min >>> 0x7ffff6b4a030 0> max > >>>> >>>> def_stmt _19 = ~_8; >>>> version:19> >>>> >>>> So what is happening is evrp converted: >>>> ct_12 = ct_5 + -1; >>>> Into >>>> ct_12 = ct_5 == 1 ? 0 : 1; >>>> (this was done before my patch) >>> Note this COND_EXPR is supposed to be combined >>> with its single use in a GIMPLE_COND ... >> I Noticed it was not doing it (before my patch) inside evrp either. > I think it is at most done in forwprop, but even then it likely > lacks a fold pattern - we only seem to forward comparisons > into GIMPLE_CONDs explicitely, leaving the rest to > match.pd patterns. > >>>> And then it gets simplified to: >>>> _8 = ct_5 == 1; >>>> _19 = ~_8; >>>> ct_12 = (int) _19; >>>> (after my match.pd patch) >>> which this one then breaks. I suppose instead of replacing >>> ct_12 adjusting the GIMPLE_COND directly might be >>> a better approach ... or not folding the generated COND_EXPR. >> I was going to try to see where COND_EXPR is created but it is late >> and there seems to be other issues going on too. >> For example, the above really should have been converted to: >> _19 = ct_5 != 1; >> ct_12 = (int) _19; >> >> This might be a gimple-match issue where the conditional part is >> always emitted without being simplified with the ~ part; COND_EXPR has >> those kind of issues :). > No, we always re-simplify things, but there might be no > (bit_not (eq @0 integer_onep)) simplifier. > > Oddly enough > > _Bool foo (int x) > { > _Bool tem = x == 1; > return ~tem; > } > > is simplified to return 1 via matching > > /* Fold ~X op C as X op' ~C, where op' is the swapped comparison. */ > (for cmp (simple_comparison) > scmp (swapped_simple_comparison) > (simplify > (cmp (bit_not@2 @0) CONSTANT_CLASS_P@1) > (if (single_use (@2) > && (TREE_CODE (@1) == INTEGER_CST || TREE_CODE (@1) == VECTOR_CST)) > (scmp @0 (bit_not @1))))) > > Richard. > > Which actually looks enticingly similar to what I'm seeing in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100774. IN that code, Folding statement: _1 = ~b_6; is not turning ~[1,1] into [0,0] but rather leaving it as varying.  it eventually fills the values in  _1 = 0;   if (_1 != 0)     goto ; [INV but it doesnt simply properly.