From patchwork Thu Jul 13 08:35:44 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 107587 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1921252qge; Thu, 13 Jul 2017 01:36:08 -0700 (PDT) X-Received: by 10.101.72.207 with SMTP id o15mr8154845pgs.73.1499934968870; Thu, 13 Jul 2017 01:36:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499934968; cv=none; d=google.com; s=arc-20160816; b=ix+ZVR5plkdiofLnzlwrWx/brG7V0rYm9+uat2i3PlEwGVHtaCBcT1P+nYd8+nZ1XO ojkYEnc2rYSHHfr4oeLZSPpsIoJCXu0D1VT1Gt1pY+4SMkBCDuq6Q7OqZ3cRyU2U4cYn I/o42TBI9eESZbGgr+LzIhfKU6fIQTtf+FpmzkS7K98QipunSw8CrHZNKAhLlOfux3r+ PuM94FtSfnn3uKflHgzd0QkqwLYN1RF5jOVz2Cj4pALZyk/R0G9i4Y90DrpyaVB16KNa cUinM80q87jyPznC5Gstk1MAMaATf2AH/OF9rtLFKTHFK4T3/RGM+9xzW6czvpbnmWtd sQ1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:message-id:date:subject:mail-followup-to:to :from:delivered-to:sender:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:mailing-list:dkim-signature :domainkey-signature:arc-authentication-results; bh=xL9BlRPK4vhiyRYeWlC5FGAuni9zlcqn9kq/ER7xQ5M=; b=rxFJEtfMIA5fLmGsvGrrrQa4ULL6wIf7SsMUdhQ0RAeCawHhYin4kyduPQzv7Ozf+b BB0XsM0TXhGRcrk5VdA4aA1HHtzUUOV4b9VxUDoc7TX2KLBnBxw2z1ghKh59ybjqLvXV hRvRM4LyvqsWaYrqQN36DdRGpMdyAG3hE6PwYu686+UJD9aprc5AS2f1yhYU3SttA4K6 VQRHTc2yfDQikD6vJ2OosWPBg69Cudz5oASxjfCI/3+7opCvN/uk2W20pCLF6omb0fFS ZyCJMjnwhVyPala91+uZ+z5761gl48xUW1pvzq/IAjU4OelF/89TA4cnvGncitnxfsOB Zh6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.b=BLOFTDpp; spf=pass (google.com: domain of gcc-patches-return-457990-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-457990-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id s63si3779746pfi.251.2017.07.13.01.36.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 01:36:08 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-return-457990-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.b=BLOFTDpp; spf=pass (google.com: domain of gcc-patches-return-457990-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-457990-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type; q=dns; s= default; b=NSAPm0naLJYc34vpz0VleoiwdGHakl02O0by2A5wq/aT6KqWBPplI VBuqeB3iJttC2HGVKbhSy1LMgUdgGcEt5287bT39qzI4jCfvC+GNZBfCy2Crbk0+ OyWr6FjQH9gbHQ8Hhhx2tEUdZjVEro5VKHLlDFjUOsFHqr9kAt6s2s= 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:from :to:subject:date:message-id:mime-version:content-type; s= default; bh=1Wj3MMMlRFRPIY5tpRKxWzwcJmQ=; b=BLOFTDppwSlbun39lzeR HOd6A1Y42Q5uCo20zCaRmM8p/pfvEGxxdsV/n1RqelF0YGCSchRgiL62kgt+dvx2 zPfpPHR/ck2buzo8q9zqCLPfB19jBAUQhNfiPdyZBT3DhXp1NK1AVbb7+Pz/oJ56 ClcuKCG9DjdOKs16gvY0oM0= Received: (qmail 39433 invoked by alias); 13 Jul 2017 08:35:53 -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 34807 invoked by uid 89); 13 Jul 2017 08:35:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=no version=3.3.2 spammy=martins, sensitivity, Martins, enforcing X-HELO: mail-wr0-f175.google.com Received: from mail-wr0-f175.google.com (HELO mail-wr0-f175.google.com) (209.85.128.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Jul 2017 08:35:49 +0000 Received: by mail-wr0-f175.google.com with SMTP id 77so49460790wrb.1 for ; Thu, 13 Jul 2017 01:35:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:subject:date:message-id :user-agent:mime-version; bh=xL9BlRPK4vhiyRYeWlC5FGAuni9zlcqn9kq/ER7xQ5M=; b=SHo10MV46KNFkM4FjvmF8wPrlX3w8Y94mwnc7xcZwxKcN6e4X2QyGn6jAoR6xpy4J2 WKexVK/Db4hQucjZmRq6tRqqaEqM09cqkxILMuYXxjlvSm91tRf20u8pJ2a+TuH3bh03 uJJrMMkAI9Y9MOzW/Ioqn/ALdU3PGw8SpxLyCAXDy5UEeGbQanSAANVs33X1f4bEuuVl H6fWum1Woz2Ordc+fAsHUMli0coULfxBqFxrd0RnCYDLv977jYQ6LZfSb8O28kDH89uE SJLzM/IIUVyRD63umkRQ4L0TsySxbkE/eDD53HsRGvW278jCO3kSYdCyyXifnauDAxdZ jhMQ== X-Gm-Message-State: AIVw112vLBp8cGLkpdC0EzovXuEy3N8DemCXdnb2g0gebcXpOwIQBUQD 2n4D46vHWT1kfn4GkD+v9A== X-Received: by 10.223.150.74 with SMTP id c10mr859082wra.124.1499934947266; Thu, 13 Jul 2017 01:35:47 -0700 (PDT) Received: from localhost (92.40.249.184.threembb.co.uk. [92.40.249.184]) by smtp.gmail.com with ESMTPSA id y12sm4906867wrb.39.2017.07.13.01.35.45 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Jul 2017 01:35:46 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: [00/77] Add wrapper classes for machine_modes Date: Thu, 13 Jul 2017 09:35:44 +0100 Message-ID: <8760ewohsv.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 This series is an update of: https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00766.html It adds a group of wrapper classes around machine_mode for modes that are known to belong to, or need to belong to, a particular mode_class. For example, it adds a scalar_int_mode wrapper for MODE_INT and MODE_PARTIAL_INT modes, a scalar_float_mode wrapper for MODE_FLOAT and MODE_DECIMAL_FLOAT modes, and so on. These wrapper classes aren't meant to form an inheritance tree in the way that rtx_insn or gimple do. They really just bundle a machine_mode with a static assertion that a particular condition holds. In principle there could be a wrapper class for any useful condition. The reason for using wrapper classes is that they provide more build-time checking that modes have the right class. In the best cases they avoid the need for any runtime assertions, but "at worst" they force the assertion further up to the place that derives the mode, often a TYPE_MODE or a GET_MODE. Enforcing the condition at this level should catch mistakes earlier and with less sensitivity to the following code paths. It should also make the basis for the assertion more obvious; e.g. scalar_int_mode uses of TYPE_MODEs are often guarded at some level by an INTEGRAL_TYPE_P test. I know of three specific cases in which the static type checking forced fixes for things that turned out to be real bugs (although we didn't know that at the time, otherwise we'd have posted patches). They were later fixed for trunk by: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01783.html https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02983.html https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02896.html It also found problems that seemed to be latent, but the fixes for those went into GCC 7, so there are none to go with this iteration of the series. The most common sources of problems seemed to be using VOIDmode or BLKmode where a scalar integer was expected (e.g. when getting the number of bits in the value), and simplifying vector operations in ways that only make sense for scalars. The series is part of the SVE submission and includes most of the changes in group C from: https://gcc.gnu.org/ml/gcc/2016-11/msg00033.html Since SVE has variable-length vectors, the SVE series as a whole needs to change the size of a vector mode from being a known compile-time constant to being (possibly) a run-time invariant. It then needs to do the same for unconstrained machine_modes, which might or might not be vectors. Introducing these new constrained types for scalar and complex modes means that we can continue to treat them as having a constant size. Mostly this is just a tweaked version of the original series, rebased onto current trunk. There is one significant difference though: the first iteration treated machine_mode as an all-encompassing wrapper class whereas this version keeps it as an enum. Treating it as a wrapper class made it consistent with the other classes and meant that it would be easier in future to use member functions to access mode properties (e.g. "mode.size ()" rather than "GET_MODE_SIZE (mode)") if that was thought to be a good thing. However, Martin's recent memset/memcpy warning shows that there are still many places that expect machine_modes to be POD-ish, so in the end it seemed better to leave machine_mode as an enum for now. Also, I've now split the scalar_mode patch into 11 separate patches, since it was very difficult to review/reread in its old form. In terms of compile time, the series is actually a very slight win for --enable-checking=release builds and a more marked win for --enable-checking=yes,rtl. That might seem unlikely, but there are several possible reasons: (1) The series makes all the machmode.h macros that used: __builtin_constant_p (M) ? foo_inline (M) : foo_array[M] forward to an ALWAYS_INLINE function, so that (a) M is only evaluated once and (b) __builtin_constant_p is applied to a variable, and so is deferred until later passes. This helped the optimisation to fire in more cases and to continue firing when M is a class rather than a raw enum. (2) The series has a tendency to evaluate modes once, rather than continually fetching them from (sometimes quite deep) rtx nests. Refetching a mode is a particular problem if a call comes between two uses, since the compiler then has to re-evaluate the whole thing. (3) The series introduces many uses of new SCALAR_*TYPE_MODE macros, as alternatives to TYPE_MODE. The new macros avoid the usual: (VECTOR_TYPE_P (TYPE_CHECK (NODE)) \ ? vector_type_mode (NODE) : (NODE)->type_common.mode) and become direct field accesses in release builds. VECTOR_TYPE_P would be consistently false for these uses, and thus predictable at runtime. However, we can't predict them to be false at compile time without profile feedback, since in other uses of TYPE_MODE the VECTOR_TYPE_P condition can be quite likely or even guaranteed. This means (for example) that call-clobbered registers would usually be treated as clobbered by the condition as a whole. I tested this by compiling the testsuite for: aarch64-linux-gnu alpha-linux-gnu arc-elf arm-linux-gnueabi arm-linux-gnueabihf avr-elf bfin-elf c6x-elf cr16-elf cris-elf epiphany-elf fr30-elf frv-linux-gnu ft32-elf h8300-elf hppa64-hp-hpux11.23 ia64-linux-gnu i686-pc-linux-gnu i686-apple-darwin iq2000-elf lm32-elf m32c-elf m32r-elf m68k-linux-gnu mcore-elf microblaze-elf mips-linux-gnu mipsisa64-linux-gnu mmix mn10300-elf moxie-rtems msp430-elf nds32le-elf nios2-linux-gnu nvptx-none pdp11 powerpc-linux-gnuspe powerpc-eabispe powerpc64-linux-gnu powerpc-ibm-aix7.0 riscv64-elf rl78-elf rx-elf s390-linux-gnu s390x-linux-gnu sh-linux-gnu sparc-linux-gnu sparc64-linux-gnu sparc-wrs-vxworks spu-elf tilegx-elf tilepro-elf xstormy16-elf v850-elf vax-netbsdelf visium-elf x86_64-darwin x86_64-linux-gnu xtensa-elf and checking that there were no changes in assembly. Also tested in the normal way on aarch64-linux-gnu, powerc64-linux-gnu and x86_64-linux-gnu. Thanks, Richard