From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rguenther@suse.de>
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28])
 by sourceware.org (Postfix) with ESMTPS id DE1C53858C3A
 for <gcc-patches@gcc.gnu.org>; Tue, 26 Oct 2021 13:38:43 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE1C53858C3A
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
 by smtp-out1.suse.de (Postfix) with ESMTP id E2D6A218ED;
 Tue, 26 Oct 2021 13:38:42 +0000 (UTC)
Received: from murzim.suse.de (murzim.suse.de [10.160.4.192])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by relay2.suse.de (Postfix) with ESMTPS id D2D74A3B95;
 Tue, 26 Oct 2021 13:38:42 +0000 (UTC)
Date: Tue, 26 Oct 2021 15:38:42 +0200 (CEST)
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
cc: Jonathan Wakely <jwakely@redhat.com>, 
 Tamar Christina <Tamar.Christina@arm.com>, 
 "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>, nd <nd@arm.com>
Subject: Re: [PATCH] middle-end: fix de-optimizations with bitclear patterns
 on signed values
In-Reply-To: <20211026133625.GZ304296@tucnak>
Message-ID: <qsqs5qon-6q43-5s2o-7o1q-3n9ors925o56@fhfr.qr>
References: <patch-14938-tamar@arm.com>
 <qo12s6sr-59s-72q-5r8q-3nn2643nn78p@fhfr.qr>
 <VI1PR08MB5325F37BC71A4A26E080FC22FF839@VI1PR08MB5325.eurprd08.prod.outlook.com>
 <9o14q41-qs41-64qn-poo0-o29p3r98rr5s@fhfr.qr>
 <VI1PR08MB53256209AA24F636E6496E09FF849@VI1PR08MB5325.eurprd08.prod.outlook.com>
 <7s13204o-n6os-699-q544-65sr84rprnsq@fhfr.qr>
 <VI1PR08MB532553ABCB6EB4C05D835406FF849@VI1PR08MB5325.eurprd08.prod.outlook.com>
 <n56qsp81-3opn-3052-1950-r8144nn094rr@fhfr.qr>
 <20211026132008.GY304296@tucnak> <or38orr-20q2-58p0-6646-8on2sn0p341@fhfr.qr>
 <20211026133625.GZ304296@tucnak>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, 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 <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Oct 2021 13:38:45 -0000

On Tue, 26 Oct 2021, Jakub Jelinek wrote:

> On Tue, Oct 26, 2021 at 03:21:55PM +0200, Richard Biener wrote:
> > On Tue, 26 Oct 2021, Jakub Jelinek wrote:
> > 
> > > On Tue, Oct 26, 2021 at 03:13:29PM +0200, Richard Biener wrote:
> > > > try
> > > >   auto c = ...;
> > > >   signed char c2 = c;
> > > >   return c2 >= ...
> > > > then
> > > 
> > > That won't work, at least when using <compare>, which is what we with the
> > > optimization want to deal with primarily.
> > > Because std::partial_ordering etc. aren't implicitly nor explicitly
> > > convertible to int or signed char etc.
> > > Sure, one could in the testcase define its own std::strong_ordering etc.
> > > and define a conversion operator for it...
> > 
> > So how do we end up with the signed char case in the first place?
> > Is the frontend using a type that's target dependent?
> 
> <compare> uses explicitly signed char:
> namespace std
> {
>   // [cmp.categories], comparison category types
>   namespace __cmp_cat
>   {
>     using type = signed char;
>     enum class _Ord : type { equivalent = 0, less = -1, greater = 1 };
>     enum class _Ncmp : type { _Unordered = 2 };
> ...
> and __cmp_cat::type is what is used as type of _M_value of std::*_ordering
> -fsigned-char vs. -funsigned-char make no difference on the testcases on
> x86, but as mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589#c24
> some target decisions like load_extend_op uses in fold-const.c can affect
> it.  See https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570714.html

Eh, I see.  So there are alrady testcases covering the issues on
the affected targets.

So ignore my comment about adding additional testcases.

Richard.