From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58853 invoked by alias); 8 Nov 2017 09:39:33 -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 39872 invoked by uid 89); 8 Nov 2017 09:39:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:Wed, promotes X-HELO: mail-wm0-f52.google.com Received: from mail-wm0-f52.google.com (HELO mail-wm0-f52.google.com) (74.125.82.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Nov 2017 09:39:24 +0000 Received: by mail-wm0-f52.google.com with SMTP id s66so8971715wmf.5 for ; Wed, 08 Nov 2017 01:39:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=wcOqjrUCrzOkBrc7qytpKMWQe1TNwD6T90EJI6WN7ms=; b=eIoHj6ATKc7pWQq7tuDLYLVokXFH1XYWw9K6XtJ2I6zKc7Rxkafee/gSUgtq70DkIe gF6aqhGtBX6mRH4rCCO7BxRYElkSaajBJ8lhhpQQlKdTCJ+Y4SEGZ/x7AgEPlPE2/kyD gKn0SWdiRcgt/LucE7/+EsKX4QD6S7G7EHYEIyGyuJ/X5ZMcnA9+hJSpMGw6sgHuiRxT 2ehlP11qitspyAUGcK3dGBkbuAxHfZOP/UBPU4oWSXMmFW6pmlmXPxC5qDlZW8hiQvl/ xBj4A4PpimV+c6p1hnCp9sk+81TE4Dpyaom6H97iPHXgSXBxucXhM/CQF/Ofr7bgrUo3 Wlkw== X-Gm-Message-State: AJaThX7DQThUU4acru/KmPCX3xgez/brR0DZO0IJx1p162z0Zo7YSsNX 1gfcVVBYq4F6yeMPEfwX6LQvgqU28UI= X-Google-Smtp-Source: ABhQp+QlFC1YAgTOd0/szU9rJEcWrwwT4g3mhzFTzmwxZ/IyQkYkxm7rofSJZ6932spG+cLWWuIcCA== X-Received: by 10.28.61.213 with SMTP id k204mr1423225wma.110.1510133962584; Wed, 08 Nov 2017 01:39:22 -0800 (PST) Received: from localhost ([2.25.234.120]) by smtp.gmail.com with ESMTPSA id m3sm5680177wrf.56.2017.11.08.01.39.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Nov 2017 01:39:21 -0800 (PST) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Eric Botcazou , GCC Patches , richard.sandiford@linaro.org Cc: Eric Botcazou , GCC Patches Subject: Re: [000/nnn] poly_int: representation of runtime offsets and sizes 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> Date: Wed, 08 Nov 2017 09:51:00 -0000 In-Reply-To: (Richard Biener's message of "Wed, 25 Oct 2017 15:08:24 +0200") Message-ID: <87lgjh5cu1.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-11/txt/msg00564.txt.bz2 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? Thanks, Richard