From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52330 invoked by alias); 9 Dec 2016 12:48:45 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 115999 invoked by uid 89); 9 Dec 2016 12:48:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=forgotten, vein, constrained, firing X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Dec 2016 12:48:05 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BDD2C707; Fri, 9 Dec 2016 04:48:03 -0800 (PST) Received: from localhost (e105548-lin.manchester.arm.com [10.45.32.67]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 688713F477 for ; Fri, 9 Dec 2016 04:48:03 -0800 (PST) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Subject: [0/67] Add wrapper classes for machine_modes Date: Fri, 09 Dec 2016 12:48:00 -0000 Message-ID: <87h96dp8u6.fsf@e105548-lin.cambridge.arm.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-12/txt/msg00766.txt.bz2 This series includes most of the changes in group C from: https://gcc.gnu.org/ml/gcc/2016-11/msg00033.html The idea is to add wrapper classes around machine_mode_enum for specific groups of modes, such as scalar integers, scalar floats, complex values, etc. This has two main benefits: one specific to SVE and one not. The SVE-specific benefit is that it helps to introduce the concept of variable-length vectors. To do that we need to change the size of a vector mode from being a known compile-time constant to being (possibly) a run-time invariant. We then need to do the same for unconstrained machine_modes, which might or might not be vectors. Introducing these new constrained types means that we can continue to treat them as having a constant size. The other benefit is that it uses static type checking to enforce conditions that are easily forgotten otherwise. The most common sources of problems seem to be: (a) using VOIDmode or BLKmode where a scalar integer was expected (e.g. when getting the number of bits in the value). (b) simplifying vector operations in ways that only make sense for scalars. The series helps with both of these, although we don't get the full benefit of (b) until variable-sized modes are introduced. 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 The group C patches in ARM/sve-branch did slow compile time down a little. I've since taken steps to avoid that: - Make the tailcall pass handle aggregate parameters and return values (already in trunk). - Turn some of the new wrapper functions into inline functions. - Make 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. - In a similar vein, make sure that conditions like: SImode == DImode are treated as builtin_constant_p by gencondmd, so that .md patterns with those conditions are dropped. With these changes the series is actually a very slight compile-time win. That might seem unlikely, but there are several possible reasons: 1. The machmode.h macro change above might allow more constant folding. 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 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, but call-clobbered registers would usually be treated as clobbered by the condition as a whole. Maybe (3) is the most likely reason. 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 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 and x86_64-linux-gnu. The series depends on the already-posted: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01657.html Sorry that this is so late, been distracted by other things. Even if we're too far into stage 3 for SVE itself to go in, I was hoping this part (which was kind-of posted during stage 1) could go in independently. Thanks, Richard