From patchwork Tue May 28 15:42:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 1106377 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-501786-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=axis.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45CymN4jkmz9s1c for ; Wed, 29 May 2019 01:43:14 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :message-id:from:to:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=mu/n7tfxYdHDan7S wBLb4LWvKlS05TpVpYrFxSsHFdxbiVJcrbkcipNaRVSsrHsfBbK49+tpUjowMkj/ lBLlHBIfPlxIsRZ/cfyhElzroZ2dRelvG54/EwkYK+0qzjEymud/HCzbL1QxZNnt llEhK6Z1LDhYlLQKygOT7qONXQ8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :message-id:from:to:subject:mime-version:content-type :content-transfer-encoding; s=default; bh=V7WH1NodiHheLmFuMiJg0p 0DG+M=; b=pDDRrlNHwWUe6wq0xghRkqHDHoP+miU35kmqQCv8c43HcZTxm9Wpmr bncukC0U5s5oG16EShAKiPMEMbX2N8Z2SL2TBKt75d0EZxQr7kdIOX6Ws7tC6+Hu GiMUmHVvo93qMUhuknz7bHQKXzJK97tFZFBMGWy0i04GdbC2jsOow= Received: (qmail 50033 invoked by alias); 28 May 2019 15:43:06 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 50020 invoked by uid 89); 28 May 2019 15:43:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=interpretation, cap, brgds, corners X-HELO: bastet.se.axis.com Received: from bastet.se.axis.com (HELO bastet.se.axis.com) (195.60.68.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 May 2019 15:43:01 +0000 Received: from localhost (localhost [127.0.0.1]) by bastet.se.axis.com (Postfix) with ESMTP id 5482718592 for ; Tue, 28 May 2019 17:42:59 +0200 (CEST) X-Axis-User: NO X-Axis-NonUser: YES Received: from bastet.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bastet.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id zHlIlBAfOwvC for ; Tue, 28 May 2019 17:42:56 +0200 (CEST) Received: from boulder03.se.axis.com (boulder03.se.axis.com [10.0.8.17]) by bastet.se.axis.com (Postfix) with ESMTPS id E22F718590 for ; Tue, 28 May 2019 17:42:56 +0200 (CEST) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 81F911E235 for ; Tue, 28 May 2019 17:42:56 +0200 (CEST) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 765671E234 for ; Tue, 28 May 2019 17:42:56 +0200 (CEST) Received: from seth.se.axis.com (unknown [10.0.2.172]) by boulder03.se.axis.com (Postfix) with ESMTP for ; Tue, 28 May 2019 17:42:56 +0200 (CEST) Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.88.21.50]) by seth.se.axis.com (Postfix) with ESMTP id 69A272162; Tue, 28 May 2019 17:42:56 +0200 (CEST) Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id x4SFgtDl031183; Tue, 28 May 2019 17:42:56 +0200 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id x4SFgtNf031179; Tue, 28 May 2019 17:42:55 +0200 Date: Tue, 28 May 2019 17:42:55 +0200 Message-Id: <201905281542.x4SFgtNf031179@ignucius.se.axis.com> From: Hans-Peter Nilsson To: gcc-patches@gcc.gnu.org Subject: Patch: don't cap TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE MIME-Version: 1.0 TL;DR: instead of capping TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE, search for the largest fitting size from scalar_int_mode modes supported by the target using targetm.scalar_mode_supported_p. --------- In initialize_sizetypes, MAX_FIXED_MODE_SIZE is used as an upper limit to the *precision* of the bit size of the size-type (typically address length) of the target, which is wrong. The effect is that if a 32-bit target says "please don't cook up pieces larger than a register size", then we don't get more precision in address-related calculations than that, while the bit-precision needs to be at least (precision + LOG2_BITS_PER_UNIT + 1) with precision being the size of the address, to diagnose overflows. There are gcc_asserts that guard this, causing ICE when broken. This MAX_FIXED_MODE_SIZE usage comes from r118977 (referencing PR27885 and PR28176) and was introduced as if MAX_FIXED_MODE_SIZE is the size of the largest supported type for the target (where "supported" is in the most trivial sense as in can move and add). But it's not. MAX_FIXED_MODE_SIZE is arguably a bit vague, but documented as "the size in bits of the largest integer machine mode that should actually be used. All integer machine modes of this size or smaller can be used for structures and unions with the appropriate sizes." While in general the documentation sometimes differs from reality, that's mostly right, with "should actually be" meaning "is preferably": it's the largest size that the target indicates as beneficial of use besides that directly mapped from types used in the source code; sort-of a performance knob. (I did a static reality code check looking for direct and indirect uses before imposing this my own interpretation and recollection.) Typical use is when gcc finds that some operations can be combined and synthesized to optionally use a wider mode than seen in the source (but mostly copying). Then this macro sets an upper limit to the those operations, whether to be done at all or the chunk-size. Unfortunately some of the effects are unintuitive and I wouldn't be surprised if this de-facto affects ABI corners. It's not something you tweak more than once for a target. Two tests pass with this fixed for cris-elf (MAX_FIXED_MODE_SIZE 32): gcc.dg/attr-vector_size.c and gcc.dg/pr69973.c, where the lack of precision (32 bits instead of 64 bits for bitsizetype) caused an consistency check to ICE, from where I tracked this. Regarding the change, MAX_FIXED_MODE_SIZE is still mentioned but just to initialize the fall-back largest-supported precision. Sometimes the target supports no larger mode than that of the address, like for a 64-bit target lacking support for larger sizes (e.g. TImode), as in the motivating PR27885. I guess they can still get ICE for overflowing address-calculation checks, but that's separate problem, fixable by the target. I considered making a separate convenience function as well as amending smallest_int_mode_for_size (e.g., an optional argument to have smallest_mode_for_size neither abort or cap at MAX_FIXED_MODE_SIZE) but I think the utility is rather specific to this use. We rarely want to both settle for a smaller type than the one requested, and that possibly being larger than MAX_FIXED_MODE_SIZE. --------- Regtested cris-elf and x86_64-linux-gnu, and a separate cross-build for hppa64-hp-hpux11.11 to spot-check that I didn't re-introduce PR27885. (Not a full cross-build, just building f951 and following initialize_sizetypes in gdb to see TRT happening.) Ok to commit? gcc: * stor-layout.c (initialize_sizetypes): Set the precision of bitsizetype to the size of largest integer mode supported by target, not necessarily MAX_FIXED_MODE_SIZE. brgds, H-P --- gcc/stor-layout.c.orig Sat May 25 07:12:49 2019 +++ gcc/stor-layout.c Tue May 28 04:29:10 2019 @@ -2728,9 +2728,36 @@ initialize_sizetypes (void) gcc_unreachable (); } - bprecision - = MIN (precision + LOG2_BITS_PER_UNIT + 1, MAX_FIXED_MODE_SIZE); - bprecision = GET_MODE_PRECISION (smallest_int_mode_for_size (bprecision)); + bprecision = precision + LOG2_BITS_PER_UNIT + 1; + + /* Find the precision of the largest supported mode equal to or larger + than needed for the bitsize precision. This may be larger than + MAX_FIXED_MODE_SIZE, which is just the largest preferred size. */ + machine_mode bpmode; + unsigned int largest_target_precision = MAX_FIXED_MODE_SIZE; + + FOR_EACH_MODE_IN_CLASS (bpmode, MODE_INT) + { + scalar_int_mode smode = scalar_int_mode::from_int (bpmode); + unsigned int mode_prec = GET_MODE_PRECISION (smode); + + if (!targetm.scalar_mode_supported_p (smode)) + continue; + + if (mode_prec > largest_target_precision) + largest_target_precision = mode_prec; + + if (mode_prec >= (unsigned int) bprecision) + { + bprecision = mode_prec; + break; + } + } + + /* Fall back to the largest known supported size. */ + if (bpmode == VOIDmode) + bprecision = largest_target_precision; + if (bprecision > HOST_BITS_PER_DOUBLE_INT) bprecision = HOST_BITS_PER_DOUBLE_INT;