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 ESMTPS id D74EB38582A1 for ; Wed, 22 Feb 2023 15:19:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D74EB38582A1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677079191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PVWweKCzoycJJDPxjehwWK1YVbsPuAzzirNEpHS/W58=; b=CDaObC3kJWyxqoHFtHWby6/exqqYxCa5EOYmITwxS7aXIR8i2Ldy1GMkhO0LMqWk3enkPj nxVszDc2mE6Krj54A9jGp39bPZNQGWwMUr+n9F8k2It9/QCtLs7nDTAoBB0ujgFerHG6ar LCxoK8HOba2+EOU+ja73/4d87OpHcQM= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-94-9stoSOqvOOOmHNH2dp3pZA-1; Wed, 22 Feb 2023 10:19:49 -0500 X-MC-Unique: 9stoSOqvOOOmHNH2dp3pZA-1 Received: by mail-qv1-f70.google.com with SMTP id pm5-20020ad446c5000000b0056eb3830243so3788630qvb.16 for ; Wed, 22 Feb 2023 07:19:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=4tjTJL74hjsY5L3p6zJRF6ix+c1NZu1Q0FJB6vRFmQs=; b=J9DEp3ERbeJUvvxu1pr6eMeZIdoQLtPe6bPc5Ber2j7Oo64yNv0iB38BEhDRbbZ40J GDUZWoVX7zC9jYO4FeCT0aZ2+4uv757RIUapIkJU7ETDNrj7KY3mA0+FBaU7I8HXc+71 x/YqyeEZLzx1DtRQYRmw7K4aJ14BWUlzU/m4yz3F+WiEj5BykMeSduccxO/JA4duN2Tm lbIUCQMst8g8rt75U0VqGuI0MNNFxV2En/TeMtjgw267+YbV/fw8LWFpi82YRzmQE1qO JhB9edD9nOaWfxBRzWSLveub1BfS4AY25UjPcaz7kf8IRUgf/5HT0hDXvQcA0xoqZeZa m4Nw== X-Gm-Message-State: AO0yUKXEXDFGSyN1W4Ir7XsYrVRGpJ5HyPjvapfJQbq7Hz3LMWd70Xfa PT23q9EWVrCAv/Z4Seu1u9QIQI7C4DLEsfwLhqHrHDejCGE4wls/mPGX26pxfKo0u6t3ETXTkaa yT6Kw34t5hCqnPLJpJw== X-Received: by 2002:a05:6214:21e8:b0:56b:ee0d:e3b6 with SMTP id p8-20020a05621421e800b0056bee0de3b6mr13680007qvj.1.1677079188711; Wed, 22 Feb 2023 07:19:48 -0800 (PST) X-Google-Smtp-Source: AK7set/SeUhOMREeA6Rxm6hhZ1ZOJ2OqQ5L2D7VdRxQgeHl+QyNU/q2F/9yhT1UrNT+QhArNDqnyYA== X-Received: by 2002:a05:6214:21e8:b0:56b:ee0d:e3b6 with SMTP id p8-20020a05621421e800b0056bee0de3b6mr13679959qvj.1.1677079188232; Wed, 22 Feb 2023 07:19:48 -0800 (PST) Received: from ?IPV6:2607:fea8:a263:f600::de2a? ([2607:fea8:a263:f600::de2a]) by smtp.gmail.com with ESMTPSA id n123-20020a37bd81000000b006ee8874f5fasm1908061qkf.53.2023.02.22.07.19.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Feb 2023 07:19:47 -0800 (PST) Message-ID: <9c59b35e-e16b-fecb-5623-4fe4022264f4@redhat.com> Date: Wed, 22 Feb 2023 10:19:45 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583] To: Tamar Christina , Richard Biener , Richard Sandiford Cc: Tamar Christina via Gcc-patches , nd , "jlaw@ventanamicro.com" References: <77142b9b-7af8-eb04-e596-6dd2f97aff9a@redhat.com> From: Andrew MacLeod In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------qA54vytAIclH8qIGk9NGU89s" Content-Language: en-US X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------qA54vytAIclH8qIGk9NGU89s Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/22/23 08:06, Tamar Christina wrote: > Hi Andrew, > >> all the range-op integer code is in gcc/range-op.cc.  As this is a basic >> binary operation, you should be able to get away with implementing a >> single routine,  wi_fold () which adds 2 wide int bounds  together and >> returns a result.  THis si the implelemntaion for operator_plus. >> >> void >> operator_plus::wi_fold (irange &r, tree type, >>                         const wide_int &lh_lb, const wide_int &lh_ub, >>                         const wide_int &rh_lb, const wide_int &rh_ub) const >> { >>   wi::overflow_type ov_lb, ov_ub; >>   signop s = TYPE_SIGN (type); >>   wide_int new_lb = wi::add (lh_lb, rh_lb, s, &ov_lb); >>   wide_int new_ub = wi::add (lh_ub, rh_ub, s, &ov_ub); >>   value_range_with_overflow (r, type, new_lb, new_ub, ov_lb, ov_ub); >> } >> >> >> you shouldn't have to do any of the overflow stuff at the end, just take >> the 2 sets of wide int, double their precision to start, add them >> together (it cant possible overflow right) and then return an >> int_range<2> with those bounds... >> ie >> >> void >> operator_plus::wi_fold (irange &r, tree type, >>                         const wide_int &lh_lb, const wide_int &lh_ub, >>                         const wide_int &rh_lb, const wide_int &rh_ub) const >> { >>   wi::overflow_type ov_lb, ov_ub; >>   signop s = TYPE_SIGN (type); >> >>   // Do whatever wideint magic is required to do this adds in higher >> precision >>   wide_int new_lb = wi::add (lh_lb, rh_lb, s, &ov_lb); >>   wide_int new_ub = wi::add (lh_ub, rh_ub, s, &ov_ub); >> >>   r = int_range<2> (type, new_lb, new_ub); >> } >> > So I've been working on adding support for widening plus and widening multiplication, > and my examples all work now.. but during bootstrap I hit a problem. > > Say you have a mixed sign widening multiplication, such as in: > > int decMultiplyOp_zacc, decMultiplyOp_iacc; > int *decMultiplyOp_lp; > void decMultiplyOp() { > decMultiplyOp_lp = &decMultiplyOp_zacc; > for (; decMultiplyOp_lp < &decMultiplyOp_zacc + decMultiplyOp_iacc; > decMultiplyOp_lp++) > *decMultiplyOp_lp = 0; > } > > Eventually the pointer arithmetic will generate: > > intD.7 decMultiplyOp_iacc.2_13; > long unsigned intD.11 _15; > _15 = decMultiplyOp_iacc.2_13 w* 4; > and it'll try to get the range from this. > > My implementation is just: > > void > operator_widen_mult::wi_fold (irange &r, tree type, > const wide_int &lh_lb, const wide_int &lh_ub, > const wide_int &rh_lb, const wide_int &rh_ub) const > { > signop s = TYPE_SIGN (type); > > wide_int lh_wlb = wide_int::from (lh_lb, wi::get_precision (lh_lb) * 2, s); > wide_int rh_wlb = wide_int::from (rh_lb, wi::get_precision (rh_lb) * 2, s); > wide_int lh_wub = wide_int::from (lh_ub, wi::get_precision (lh_ub) * 2, s); > wide_int rh_wub = wide_int::from (rh_ub, wi::get_precision (rh_ub) * 2, s); > > /* We don't expect a widening multiplication to be able to overflow but range > calculations for multiplications are complicated. After widening the > operands lets call the base class. */ > return operator_mult::wi_fold (r, type, lh_wlb, lh_wub, rh_wlb, rh_wub); > } > > But in this case the operands are different types and the wi_fold only gets the > type of the operation. The issue is that when increasing the precision for lh_* > I need to sign extend the value and not zero extend, but I don't seem to have > enough context here to know that I do. I'm missing the type of the operands. > > For non-widening operations this doesn't matter as the precision stays the same. > > Is there a way to get the information I need? > > we haven't had this situation before, if I understand it correctly: The LHS is a different type than both the operands, and your problem is you need to know the sign of at least operand1 in order to know whether to zero extend or to sign extend it?  huh. haven't run into that with any other bit of IL before :-P Let me think about it.  I am loathe to change range-ops itself, but we may be able to leverage the builtin-function approach to dealing with something non-standard. At least for the moment to keep you going. For the builtins, we provide a range-ops handler, *after* we look at the operands from within a gimple-context where we can still see the types, and  choose an appropriate handler.  so I'm thinking we provide 2 handlers, operator_widen_mult_signed operator_widen_mult_unsigned chosen based on whether to sign extned or zero extend op1. look at the type of operand one, and return the appropriate handler. Let me give you a skeleton.  I *think* this should do it. you can provide 2 versions of  operator_widen_mult in range-ops (so you can still inherit from operator_mult).  The should be exported I think, and the appropriate one should be called I think... Give it a try and see if it works :-P. --------------qA54vytAIclH8qIGk9NGU89s Content-Type: text/x-patch; charset=UTF-8; name="tamar.diff" Content-Disposition: attachment; filename="tamar.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2djYy9naW1wbGUtcmFuZ2Utb3AuY2MgYi9nY2MvZ2ltcGxlLXJhbmdlLW9w LmNjCmluZGV4IGQ5ZGZkYzU2OTM5Li5lNDM5MWY0YTYxNiAxMDA2NDQKLS0tIGEvZ2NjL2dpbXBs ZS1yYW5nZS1vcC5jYworKysgYi9nY2MvZ2ltcGxlLXJhbmdlLW9wLmNjCkBAIC0xNzksNiArMTc5 LDggQEAgZ2ltcGxlX3JhbmdlX29wX2hhbmRsZXI6OmdpbXBsZV9yYW5nZV9vcF9oYW5kbGVyIChn aW1wbGUgKnMpCiAgIC8vIHN0YXRlbWVudHMuCiAgIGlmIChpc19hIDxnY2FsbCAqPiAobV9zdG10 KSkKICAgICBtYXliZV9idWlsdGluX2NhbGwgKCk7CisgIGVsc2UKKyAgICBtYXliZV9ub25fc3Rh bmRhcmQgKCk7CiB9CiAKIC8vIENhbGN1bGF0ZSB3aGF0IHdlIGNhbiBkZXRlcm1pbmUgb2YgdGhl IHJhbmdlIG9mIHRoaXMgdW5hcnkKQEAgLTc2NCw2ICs3NjYsMjkgQEAgcHVibGljOgogICB9CiB9 IG9wX2Nmbl9wYXJpdHk7CiAKKy8vIFNldCB1cCBhIGdpbXBsZV9yYW5nZV9vcF9oYW5kbGVyIGZv ciBhbnkgbm9uc3RhbmRhcmQgZnVuY3Rpb24gd2hpY2ggY2FuIGJlCisvLyBzdXBwb3J0ZWQgdmlh IHJhbmdlLW9wcy4KKwordm9pZAorZ2ltcGxlX3JhbmdlX29wX2hhbmRsZXI6Om1heWJlX25vbl9z dGFuZGFyZCAoKQoreworICBpZiAoZ2ltcGxlX2NvZGUgKG1fc3RtdCkgPT0gR0lNUExFX0FTU0lH TikKKyAgICBzd2l0Y2ggKGdpbXBsZV9hc3NpZ25fcmhzX2NvZGUgKG1fc3RtdCkpCisgICAgICB7 CisJY2FzZSBXSURFTl9NVUxUX0VYUFI6CisJICBleHRlcm4gY2xhc3MgcmFuZ2Vfb3BlcmF0b3Ig Jm9wX3dpZGVuX211bHRfc2lnbmVkOworCSAgZXh0ZXJuIGNsYXNzIHJhbmdlX29wZXJhdG9yICZv cF93aWRlbl9tdWx0X3Vuc2lnbmVkOworCSAgbV92YWxpZCA9IHRydWU7CisJICBtX29wMSA9IGdp bXBsZV9hc3NpZ25fcmhzMSAobV9zdG10KTsKKwkgIG1fb3AyID0gZ2ltcGxlX2Fzc2lnbl9yaHMy IChtX3N0bXQpOworCSAgaWYgKFRZUEVfU0lHTiAoVFJFRV9UWVBFIChtX29wMSkpID09IFNJR05F RCkKKwkgICAgbV9pbnQgPSAmb3Bfd2lkZW5fbXVsdF9zaWduZWQ7CisJICBlbHNlCisJICAgIG1f aW50ID0gJm9wX3dpZGVuX211bHRfdW5zaWduZWQ7CisJZGVmYXVsdDoKKwkgIGJyZWFrOworICAg ICAgfQorfQogLy8gU2V0IHVwIGEgZ2ltcGxlX3JhbmdlX29wX2hhbmRsZXIgZm9yIGFueSBidWls dCBpbiBmdW5jdGlvbiB3aGljaCBjYW4gYmUKIC8vIHN1cHBvcnRlZCB2aWEgcmFuZ2Utb3BzLgog CmRpZmYgLS1naXQgYS9nY2MvZ2ltcGxlLXJhbmdlLW9wLmggYi9nY2MvZ2ltcGxlLXJhbmdlLW9w LmgKaW5kZXggNzQzYjg1ODEyNmUuLjFiZjYzYzVjZTZmIDEwMDY0NAotLS0gYS9nY2MvZ2ltcGxl LXJhbmdlLW9wLmgKKysrIGIvZ2NjL2dpbXBsZS1yYW5nZS1vcC5oCkBAIC00MSw2ICs0MSw3IEBA IHB1YmxpYzoKIAkJIHJlbGF0aW9uX3RyaW8gPSBUUklPX1ZBUllJTkcpOwogcHJpdmF0ZToKICAg dm9pZCBtYXliZV9idWlsdGluX2NhbGwgKCk7CisgIHZvaWQgbWF5YmVfbm9uX3N0YW5kYXJkICgp OwogICBnaW1wbGUgKm1fc3RtdDsKICAgdHJlZSBtX29wMSwgbV9vcDI7CiB9Owo= --------------qA54vytAIclH8qIGk9NGU89s--