From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 09FA73858D35 for ; Fri, 5 Nov 2021 10:01:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 09FA73858D35 Received: by mail-ed1-x529.google.com with SMTP id j21so31004807edt.11 for ; Fri, 05 Nov 2021 03:01:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LFzyHvf9rTpwA4t6hK5+pO9ObEUamo+c5DqnjY2MyuY=; b=VbJJlePXRqCFAljQFBZhJh0PqaSKIvSaE6aAuYR/BIALGWQR868ziWz4pywIMqtqOV iOe2D3YblCzntGA837oCv3Ldt1c6WdYrwsYl5nFnLEZQeEZeSnoICM2UVu3gpW0EGWem V03Ev1Y4B+SUmeTPjTvx3TKNolOShgBaB5vJnO6YsdJK4o2ZB9Q0o97E/QmxXK5N93y+ 4aoItanjng6coDlyVmEDhRf9RW3vNjEJJkqJgBHamgmWjtDp1ly+dlemrXXigBE4xrj8 LsP8R5yVEhGpLuxgQCNQHznR7nsQa2u/Yurf55cbtWJrFnLdfYdGzetnhxi14w0+wZnE SMsw== X-Gm-Message-State: AOAM5337tZ+M0BO22POOQ4Ux83o8qqzeBikQSH+lBWrVVNDOIH4YUq1V x7PMrZyoPXMlE6EIGg3kg65zUlrGKyFMJHsReHk= X-Google-Smtp-Source: ABdhPJxeapaAGwEYuBuzKnlqPc+H1tHkzNupCiFdrzWnqrAJuJFMX6EtPyvXFDNkeq6QS3zLsupVjNteCAD+0WYgVwo= X-Received: by 2002:a17:907:6d28:: with SMTP id sa40mr43571702ejc.201.1636106485607; Fri, 05 Nov 2021 03:01:25 -0700 (PDT) MIME-Version: 1.0 References: <7B702DE8-7B94-4317-BC19-610D2F406759@oracle.com> <20211105065326.GF304296@tucnak> In-Reply-To: <20211105065326.GF304296@tucnak> From: Richard Biener Date: Fri, 5 Nov 2021 11:01:14 +0100 Message-ID: Subject: Re: Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different To: Jakub Jelinek Cc: Andrew Pinski , "H. J. Lu" , gcc-patches Nick Alcock via Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 10:01:28 -0000 On Fri, Nov 5, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches wrote: > > On Thu, Nov 04, 2021 at 11:05:35PM -0700, Andrew Pinski via Gcc-patches w= rote: > > > I noticed that the macro =E2=80=9CWIDE_INT_MAX_ELTS=E2=80=9D has diff= erent values in GCC11 and GCC12 (on the same X86 machine) > > > > > > For gcc11: > > > > > > wide int max elts =3D3 > > > > > > For gcc12: > > > > > > wide int max elts =3D9 > > > > > > Does anyone know what=E2=80=99s the reason for this difference? > > > > > > Thanks a lot for any help. > > > > Yes originally, the x86 backend only used OI and XI modes for vectors > > during data movement. > > This changed with r10-5741-gc57b4c22089 which added the use of OI mode > > for TImode adding with overflow and then MAX_BITSIZE_MODE_ANY_INT > > changed from 128 to 160 (in r10-6178-gc124b345e46078) to fix the ICE > > introduced by that change . > > And then with r12-979-g782e57f2c09 removed the define of > > MAX_BITSIZE_MODE_ANY_INT. > > Now what was not mentioned in r12-979-g782e57f2c09 (or before) of why > > MAX_BITSIZE_MODE_ANY_INT was defined in the first place for x86. HJL > > assumed there was some problem of why it was defined that way but not > > realizing memory usage was the reason. > > It was defined to keep the memory usage down as you see that it is now > > almost a 3x memory increase for all wi::wide_int. > > I do think r12-979-g782e57f2c09 should be reverted with an added > > comment on saying defining MAX_BITSIZE_MODE_ANY_INT here is to > > decrease the memory footprint. > > I completely agree. Do we have permanent objects embedding wide[st]_int? I know of class loop and loop_bound. Btw, there are other targets with large integer modes (aarch64 with XImode) and not defining MAX_BITSIZE_MODE_ANY_INT Richard. > Jakub >