From patchwork Sat Mar 6 03:18:48 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 1448337 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=DRpQHzmZ; dkim-atps=neutral Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DsqZT28qMz9sW1 for ; Sat, 6 Mar 2021 14:18:56 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 89E483834425; Sat, 6 Mar 2021 03:18:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 89E483834425 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1615000732; bh=yZldtMFQMdzzD0QTtrNv5pvxnSI6yDB/67ZrhSCCvQA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=DRpQHzmZat2TQK/I6nsdqhF7XOgrfYak17hnIZHAmqxZkUjolmnNJOd2Z9GFy6vpY OTV05b0FfZOHO/pxvYqrOyz/Z9iGe34B3Omf1Pj+ZcryccpOxMln1R4VEcRRQ7MK+l LSA6TWJ3x2n/kiZiuf+xnFIMuM1J/q01G0TYwhLs= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by sourceware.org (Postfix) with ESMTPS id B98A2383E800 for ; Sat, 6 Mar 2021 03:18:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B98A2383E800 To: Subject: Committed: cris: don't define MAX_FIXED_MODE_SIZE MIME-Version: 1.0 Message-ID: <20210306031848.74418203BE@pchp3.se.axis.com> Date: Sat, 6 Mar 2021 04:18:48 +0100 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_PASS, 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-Patchwork-Original-From: Hans-Peter Nilsson via Gcc-patches From: Hans-Peter Nilsson Reply-To: Hans-Peter Nilsson Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" It's been 32 ever since the CRIS port was committed. A TODO-item of mine has been to check whether the non-default setting of MAX_FIXED_MODE_SIZE makes sense wrt. performance and/or code-size with a modern gcc. It doesn't, so it goes. The setting is now the default, GET_MODE_BITSIZE (DImode) (defaults.h) i.e. 64. Measurements at r11-7500 (f3641ac70eb0) on coremark with "-O2 -march=v10 -mno-mul-bug-workaround" shows 0.04% performance improvement with this change, and by inspection the effect is that unused and/or unneeded stack-frames are eliminated more often in the floating-point library (not in the coremark main loop, thus the marginal improvement). The floating-point library is full of 64-bit unions used to pick apart floating point numbers, so this kind of makes sense. Inspection of a simulator trace shows that this is indeed the only effect in coremark. Other local micro-benchmarks agree as to the net effect (no traces were inspected though), and the most floating-point-heavy test shows an 8% improvement. These effects are of course subject to gcc core tweaks and may make sense to be adjusted again in a future release. While MAX_FIXED_MODE_SIZE is IMO supposed to be an optional macro for performance, setting it to anything smaller than twice the size of an address exposes bad decisions in gcc middle end, sometimes leading to internal compiler errors. (It being set to 32 should *not* affect use of DImode as an integer mode; it's for "integer machine modes of this size or smaller can be used for structures and unions with the appropriate sizes".) Thus, with the default 64 instead of 32, there are two tests that now pass for the first time: gcc.dg/attr-vector_size.c and gcc.dg/tree-ssa/pr93121-1.c. gcc: * config/cris/cris.h (MAX_FIXED_MODE_SIZE): Don't define. --- gcc/config/cris/cris.h | 7 ------- 1 file changed, 7 deletions(-) diff --git a/gcc/config/cris/cris.h b/gcc/config/cris/cris.h index d691da9723c8..1f8ccc5dec98 100644 --- a/gcc/config/cris/cris.h +++ b/gcc/config/cris/cris.h @@ -352,13 +352,6 @@ extern int cris_cpu_version; with other GNU/Linux ports (i.e. elfos.h users). */ #undef PCC_BITFIELD_TYPE_MATTERS -/* This is only used for non-scalars. Strange stuff happens to structs - (FIXME: What?) if we use anything larger than largest actually used - datum size, so lets make it 32. The type "long long" will still work - as usual. We can still have DImode insns, but they will only be used - for scalar data (i.e. long long). */ -#define MAX_FIXED_MODE_SIZE 32 - /* Node: Type Layout */