From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 9B199385781D for ; Tue, 25 May 2021 14:37:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9B199385781D Received: by mail-ed1-x534.google.com with SMTP id r11so36449307edt.13 for ; Tue, 25 May 2021 07:37:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=705kywffAKHnv5gLCml1xlstdcCQJ1VLaN3dCHHXvKU=; b=Usi2fn+JmoJQ5lRjb9V8tzowKZhzQGBuTeGpJvcVrIsxmXap/5w0o0+9raE93kWdUa aYeRC/XPk71Rc7u7yW+nYB1yMW42VvaTLtLAWaO6xhZEwVyyKNDROmQDVBOrW9EYYzkG 1bRCSza/IPtO9+8+A4pdt65XmMjf1h32MVhyjLjlepJi0tiH0JWhWdgbBJhbug+ZlxLf T79+Z9fAlYeikdcz2c73xvXP7y6GvL2ldc2kKYWzDVXSJ+JHb0kaRs24HJ7U8B5QX4hA yxwWeQjMHFpomdLChM/TWhTZNtDMPn91bN1ZkMT6B3IqjcfrausnNzme/E6j0WApVqPN Ow1Q== X-Gm-Message-State: AOAM533kGm7+UL9UXeTE1TUsOEtHy8vv0LXtENMNdhHJ6f/8eV2t5Zmg 2WGP2c9cPSGnOBKrMA2gTzOhEM5CaV+pcX4GG8s= X-Google-Smtp-Source: ABdhPJyEdiU81JSx5Aih45++gDbBbNpY7djq38OvjDB/Vb8fARntG2MNj1IkcJecFWVUrt9XcBrLsJbKNy1skOxeFrE= X-Received: by 2002:aa7:df90:: with SMTP id b16mr18310834edy.361.1621953446712; Tue, 25 May 2021 07:37:26 -0700 (PDT) MIME-Version: 1.0 References: <20210518191646.3071005-1-hjl.tools@gmail.com> <20210518191646.3071005-5-hjl.tools@gmail.com> In-Reply-To: <20210518191646.3071005-5-hjl.tools@gmail.com> From: Richard Biener Date: Tue, 25 May 2021 16:37:16 +0200 Message-ID: Subject: Re: [PATCH v4 04/12] Remove MAX_BITSIZE_MODE_ANY_INT To: "H.J. Lu" Cc: GCC Patches , Richard Sandiford , Uros Bizjak , Bernd Edlinger Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, 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: Tue, 25 May 2021 14:37:29 -0000 On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote: > > It is only defined for i386 and everyone uses the default: > > #define MAX_BITSIZE_MODE_ANY_INT (64*BITS_PER_UNIT) > > Whatever problems we had before, they have been fixed now. So I don't have a strong recollection here apart from memory usage considerations with wide-int (possibly fixed by all the trailing-wide-int stuff we now have). So I'm fine if the target maintainer is - but then we probably should remove all vestiges of non-default MAX_BITSIZE_MODE_ANY_INT, or do we want to keep it just in case? Thanks, Richard. > * config/i386/i386-modes.def (MAX_BITSIZE_MODE_ANY_INT): Removed. > --- > gcc/config/i386/i386-modes.def | 15 +++------------ > 1 file changed, 3 insertions(+), 12 deletions(-) > > diff --git a/gcc/config/i386/i386-modes.def b/gcc/config/i386/i386-modes.def > index dbddfd8e48f..4e7014be034 100644 > --- a/gcc/config/i386/i386-modes.def > +++ b/gcc/config/i386/i386-modes.def > @@ -107,19 +107,10 @@ INT_MODE (XI, 64); > PARTIAL_INT_MODE (HI, 16, P2QI); > PARTIAL_INT_MODE (SI, 32, P2HI); > > -/* Mode used for signed overflow checking of TImode. As > - MAX_BITSIZE_MODE_ANY_INT is only 160, wide-int.h reserves only that > - rounded up to multiple of HOST_BITS_PER_WIDE_INT bits in wide_int etc., > - so OImode is too large. For the overflow checking we actually need > - just 1 or 2 bits beyond TImode precision. Use 160 bits to have > - a multiple of 32. */ > +/* Mode used for signed overflow checking of TImode. For the overflow > + checking we actually need just 1 or 2 bits beyond TImode precision. > + Use 160 bits to have a multiple of 32. */ > PARTIAL_INT_MODE (OI, 160, POI); > > -/* Keep the OI and XI modes from confusing the compiler into thinking > - that these modes could actually be used for computation. They are > - only holders for vectors during data movement. Include POImode precision > - though. */ > -#define MAX_BITSIZE_MODE_ANY_INT (160) > - > /* The symbol Pmode stands for one of the above machine modes (usually SImode). > The tm.h file specifies which one. It is not a distinct mode. */ > -- > 2.31.1 >