From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21661 invoked by alias); 8 Nov 2017 11:48:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 21450 invoked by uid 89); 8 Nov 2017 11:48:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=HTo:U*ebotcazou, HX-Received:10.80.158.194 X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Nov 2017 11:48:02 +0000 Received: by mail-wm0-f53.google.com with SMTP id r68so9867798wmr.1 for ; Wed, 08 Nov 2017 03:48:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=59O4Fn3JItst0bNtoBUGCc+dX0Nv26CLfhrNlFv8dbo=; b=l7uJxwDBU9Mw4XwNrNeUtUAiy6mmiSnpydz2m2Syj/gvJz2kAH4wDI/TASO3TeK6cT DFChmsemPi/jG2p7Wre9WI0j815xwhExK7aBDp2s+ocJrpqMe+lbcV6BnbIQ0KIWUibf j+66EDcMY2QoYCZMoeEpjcFLVPgk+nInh2/av2XmzewYLI6bHP6Lj4FrgcRgUNQXB7GB lPrVg7JhD9qNJC3kfYy0zIRQli2cn3aI/RoSHWTZnFbzbawcg4OKC0XkU1RVjUr6mC/T D4ADzf9QxIaQhi7/aR8RTVJgrhFCIUua3CVXPUao9S3Nf5gOcew4KkEIdKNVv/E7eQ6X 8Nig== X-Gm-Message-State: AJaThX4wHsngjA6ojbABgMzkOxsZk/qD11eBguuJpzJCvziwzqOmcy97 fDGNetFm96PqFYxoXeYEaSdr0r5fEWnr9+q2MAc= X-Google-Smtp-Source: ABhQp+T/yvvQao34lCWYYNX/75OTiUMyjVI15qaOj4Wu0n0LDzerTUpQCq2Akp4z4xIzYmqBoY7H4Z3ADy1KKetYWM4= X-Received: by 10.80.158.194 with SMTP id a60mr333255edf.182.1510141680331; Wed, 08 Nov 2017 03:48:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.143.34 with HTTP; Wed, 8 Nov 2017 03:47:59 -0800 (PST) In-Reply-To: <87lgjh5cu1.fsf@linaro.org> References: <871sltvm7r.fsf@linaro.org> <4728974.295PUQgt1k@polaris> <87o9owq35v.fsf@linaro.org> <10524871.8B8OuvVQlb@polaris> <87fua8pz6v.fsf@linaro.org> <87bmkwpv8j.fsf@linaro.org> <877evkptkr.fsf@linaro.org> <87she7tqmo.fsf@linaro.org> <87lgjh5cu1.fsf@linaro.org> From: Richard Biener Date: Wed, 08 Nov 2017 11:57:00 -0000 Message-ID: Subject: Re: [000/nnn] poly_int: representation of runtime offsets and sizes To: Richard Biener , Eric Botcazou , GCC Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00575.txt.bz2 On Wed, Nov 8, 2017 at 10:39 AM, Richard Sandiford wrote: > Richard Biener writes: >> On Wed, Oct 25, 2017 at 1:26 PM, Richard Sandiford >> wrote: >>> Richard Biener writes: >>>> On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford >>>> wrote: >>>>> Richard Biener writes: >>>>>> On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford >>>>>> wrote: >>>>>>> Richard Biener writes: >>>>>>>> On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford >>>>>>>> wrote: >>>>>>>>> Eric Botcazou writes: >>>>>>>>>>> Yeah. E.g. for ==, the two options would be: >>>>>>>>>>> >>>>>>>>>>> a) must_eq (a, b) -> a == b >>>>>>>>>>> must_ne (a, b) -> a != b >>>>>>>>>>> >>>>>>>>>>> which has the weird property that (a == b) != (!(a != b)) >>>>>>>>>>> >>>>>>>>>>> b) must_eq (a, b) -> a == b >>>>>>>>>>> may_ne (a, b) -> a != b >>>>>>>>>>> >>>>>>>>>>> which has the weird property that a can be equal to b when a != b >>>>>>>>>> >>>>>>>>>> Yes, a) was the one I had in mind, i.e. the traditional operators are >>>>>>>>>> the must >>>>>>>>>> variants and you use an outer ! in order to express the may. Of >>>>>>>>>> course this >>>>>>>>>> would require a bit of discipline but, on the other hand, if most of >>>>>>>>>> the cases >>>>>>>>>> fall in the must category, that could be less ugly. >>>>>>>>> >>>>>>>>> I just think that discipline is going to be hard to maintain in >>>>>>>>> practice, >>>>>>>>> since it's so natural to assume (a == b || a != b) == true. With the >>>>>>>>> may/must approach, static type checking forces the issue. >>>>>>>>> >>>>>>>>>>> Sorry about that. It's the best I could come up with without losing >>>>>>>>>>> the may/must distinction. >>>>>>>>>> >>>>>>>>>> Which variant is known_zero though? Must or may? >>>>>>>>> >>>>>>>>> must. maybe_nonzero is the may version. >>>>>>>> >>>>>>>> Can you rename known_zero to must_be_zero then? >>>>>>> >>>>>>> That'd be OK with me. >>>>>>> >>>>>>> Another alternative I wondered about was must_eq_0 / may_ne_0. >>>>>>> >>>>>>>> What's wrong with must_eq (X, 0) / may_eq (X, 0) btw? >>>>>>> >>>>>>> must_eq (X, 0) generated a warning if X is unsigned, so sometimes you'd >>>>>>> need must_eq (X, 0) and sometimes must_eq (X, 0U). >>>>>> >>>>>> Is that because they are templates? Maybe providing a partial >>>>>> specialization >>>>>> would help? >>>>> >>>>> I don't think it's templates specifically. We end up with something like: >>>>> >>>>> int f (unsigned int x, const int y) >>>>> { >>>>> return x != y; >>>>> } >>>>> >>>>> int g (unsigned int x) { return f (x, 0); } >>>>> >>>>> which generates a warning too. >>>>> >>>>>> I'd be fine with must_eq_p and may_eq_0. >>>>> >>>>> OK, I'll switch to that if there are no objections. >>>> >>>> Hum. But then we still warn for must_eq_p (x, 1), no? >>> >>> Yeah. The patch also had a known_one and known_all_ones for >>> those two (fairly) common cases. For other values the patches >>> just add "U" where necessary. >>> >>> If you think it would be better to use U consistently and not >>> have the helpers, then I'm happy to do that instead. >>> >>>> So why does >>>> >>>> int f (unsigned int x) >>>> { >>>> return x != 0; >>>> } >>>> >>>> not warn? Probably because of promotion of the arg. >>> >>> [Jakub's already answered this part.] >>> >>>> Shouldn't we then simply never have a may/must_*_p (T1, T2) >>>> with T1 and T2 being not compatible? That is, force promotion >>>> rules on them with template magic? >>> >>> This was what I meant by: >>> >>> Or we could suppress warnings by forcibly converting the input. >>> Sometimes the warnings are useful though. >>> >>> We already do this kind of conversion for arithmetic, to ensure >>> that poly_uint16 + poly_uint16 -> poly_int64 promotes before the >>> addition rather than after it. But it defeats the point of the >>> comparison warning, which is that you're potentially redefining >>> the sign bit. >>> >>> I think the warning's just as valuable for may/must comparison of >>> non-literals as it is for normal comparison operators. It's just >>> unfortunate that we no longer get the special handling of literals. >> >> Ok, I see. >> >> I think I have a slight preference for using 0U consistently but I haven't >> looked at too many patches yet to see how common/ugly that would be. > > OK. FWIW, that's also how we had it until very recently. I added the > known/maybe stuff in a late and probably misguided attempt to make > things prettier. > > I've pulled that part out and switched back to using U. I'll post the > new 001 patch in a sec. Should I repost all the other patches that > changed as well, or isn't it worth it for a change like that? Not worth re-posting IMHO. Richard. > Thanks, > Richard