public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com
Subject: Re: [0/67] Add wrapper classes for machine_modes
Date: Fri, 05 May 2017 07:08:00 -0000	[thread overview]
Message-ID: <59d78c7c-0a59-ed02-4d90-8a749b328091@redhat.com> (raw)
In-Reply-To: <87h96dp8u6.fsf@e105548-lin.cambridge.arm.com>

On 12/09/2016 05:48 AM, Richard Sandiford wrote:
> 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
So can we get the discussion around the prerequisite restarted -- I like 
the core ideas around building wrapper classes around machine modes, but 
obviously we can't really move forward on this without the prereqs.

jeff

  parent reply	other threads:[~2017-05-05  4:21 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-09 12:48 Richard Sandiford
2016-12-09 12:50 ` [1/67] Add an E_ prefix to mode names and update case statements Richard Sandiford
2016-12-09 12:52 ` [2/67] Make machine_mode a class Richard Sandiford
2016-12-15 22:34   ` Trevor Saunders
2016-12-09 12:53 ` [3/67] Add GDB pretty printer for machine mode classes Richard Sandiford
2016-12-09 12:54 ` [4/67] Add FOR_EACH iterators for modes Richard Sandiford
2016-12-09 12:55 ` [6/67] Make GET_MODE_WIDER return an opt_mode Richard Sandiford
2016-12-09 12:55 ` [5/67] Small tweak to array_value_type Richard Sandiford
2016-12-09 12:57 ` [8/67] Simplify gen_trunc/extend_conv_libfunc Richard Sandiford
2016-12-09 12:57 ` [7/67] Add scalar_float_mode Richard Sandiford
2016-12-09 14:19   ` David Malcolm
2016-12-09 14:30     ` Richard Sandiford
2016-12-09 12:58 ` [9/67] Add SCALAR_FLOAT_TYPE_MODE Richard Sandiford
2016-12-09 12:59 ` [10/67] Make assemble_real take a scalar_float_mode Richard Sandiford
2016-12-09 13:00 ` [0/67] Add wrapper classes for machine_modes Richard Biener
2016-12-09 13:54   ` Richard Sandiford
2016-12-09 13:00 ` [11/67] Add a float_mode_for_size helper function Richard Sandiford
2016-12-09 13:00 ` [12/67] Use opt_scalar_float_mode when iterating over float modes Richard Sandiford
2016-12-09 13:01 ` [13/67] Make floatn_mode return an opt_scalar_float_mode Richard Sandiford
2016-12-09 13:02 ` [14/67] Make libgcc_floating_mode_supported_p take a scalar_float_mode Richard Sandiford
2016-12-09 13:03 ` [16/67] Add scalar_int_mode_pod Richard Sandiford
2016-12-09 13:03 ` [15/67] Add scalar_int_mode Richard Sandiford
2016-12-09 13:04 ` [17/67] Add an int_mode_for_size helper function Richard Sandiford
2016-12-09 13:05 ` [19/67] Add a smallest_int_mode_for_size " Richard Sandiford
2016-12-09 13:05 ` [18/67] Make int_mode_for_mode return an opt_scalar_int_mode Richard Sandiford
2016-12-09 13:06 ` [20/67] Replace MODE_INT checks with is_int_mode Richard Sandiford
2016-12-09 13:07 ` [22/67] Replace !VECTOR_MODE_P with is_a <scalar_int_mode> Richard Sandiford
2016-12-09 13:07 ` [21/67] Replace SCALAR_INT_MODE_P checks " Richard Sandiford
2016-12-09 13:08 ` [24/67] Replace a != BLKmode check " Richard Sandiford
2016-12-09 13:22   ` Richard Biener
2016-12-09 14:42     ` Richard Sandiford
2016-12-09 13:08 ` [23/67] Replace != VOIDmode checks " Richard Sandiford
2016-12-09 13:09 ` [25/67] Use is_a <scalar_int_mode> for bitmask optimisations Richard Sandiford
2016-12-09 13:10 ` [27/67] Use is_a <scalar_int_mode> before LOAD_EXTEND_OP Richard Sandiford
2016-12-09 13:10 ` [26/67] Use is_a <scalar_int_mode> in subreg/extract simplifications Richard Sandiford
2016-12-09 13:11 ` [28/67] Use is_a <scalar_int_mode> for miscellaneous types of test Richard Sandiford
2016-12-09 13:12 ` [29/67] Make some *_loc_descriptor helpers take scalar_int_mode Richard Sandiford
2016-12-09 13:12 ` [30/67] Use scalar_int_mode for doubleword splits Richard Sandiford
2016-12-09 13:13 ` [31/67] Use scalar_int_mode for move2add Richard Sandiford
2016-12-09 13:14 ` [32/67] Check is_a <scalar_int_mode> before calling valid_pointer_mode Richard Sandiford
2016-12-09 13:14 ` [33/67] Add a NARROWEST_INT_MODE macro Richard Sandiford
2016-12-09 13:15 ` [34/67] Add a SCALAR_INT_TYPE_MODE macro Richard Sandiford
2016-12-09 13:16 ` [35/67] Add uses of as_a <scalar_int_mode> Richard Sandiford
2016-12-09 13:16 ` [36/67] Use scalar_int_mode in the RTL iv routines Richard Sandiford
2016-12-09 13:17 ` [37/67] Use scalar_int_mode when emitting cstores Richard Sandiford
2016-12-09 13:17 ` [38/67] Move SCALAR_INT_MODE_P out of strict_volatile_bitfield_p Richard Sandiford
2016-12-09 13:18 ` [39/67] Two changes to the get_best_mode interface Richard Sandiford
2016-12-09 13:19 ` [40/67] Use scalar_int_mode for extraction_insn fields Richard Sandiford
2016-12-09 13:20 ` [42/67] Use scalar_int_mode in simplify_shift_const_1 Richard Sandiford
2016-12-09 13:20 ` [41/67] Split scalar integer handling out of force_to_mode Richard Sandiford
2016-12-09 13:22 ` [43/67] Use scalar_int_mode in simplify_comparison Richard Sandiford
2016-12-09 13:22 ` [44/67] Make simplify_and_const_int take a scalar_int_mode Richard Sandiford
2016-12-09 13:23 ` [45/67] Make extract_left_shift " Richard Sandiford
2016-12-09 13:23 ` [46/67] Make widest_int_mode_for_size return " Richard Sandiford
2016-12-09 13:24 ` [47/67] Make subroutines of nonzero_bits operate on scalar_int_mode Richard Sandiford
2016-12-09 13:25 ` [49/67] Simplify nonzero/num_sign_bits hooks Richard Sandiford
2016-12-09 13:25 ` [48/67] Make subroutines of num_sign_bit_copies operate on scalar_int_mode Richard Sandiford
2016-12-09 13:28 ` [50/67] Add helper routines for SUBREG_PROMOTED_VAR_P subregs Richard Sandiford
2016-12-09 13:30 ` [51/67] Use opt_scalar_int_mode when iterating over integer modes Richard Sandiford
2016-12-09 13:30 ` [52/67] Use scalar_int_mode in extract/store_bit_field Richard Sandiford
2016-12-09 13:31 ` [54/67] Add explicit int checks for alternative optab implementations Richard Sandiford
2016-12-09 13:31 ` [53/67] Pass a mode to const_scalar_mask_from_tree Richard Sandiford
2016-12-09 13:33 ` [56/67] Use the more specific type when two modes are known to be equal Richard Sandiford
2016-12-09 13:33 ` [55/67] Use scalar_int_mode in simplify_const_unary_operation Richard Sandiford
2016-12-09 13:34 ` [57/67] Use scalar_int_mode in expand_expr_addr_expr Richard Sandiford
2016-12-09 13:35 ` [58/67] Use scalar_int_mode in a try_combine optimisation Richard Sandiford
2016-12-09 13:36 ` [60/67] Pass scalar_int_modes to do_jump_by_parts_* Richard Sandiford
2016-12-09 13:36 ` [59/67] Add a rtx_jump_table_data::get_data_mode helper Richard Sandiford
2016-12-09 13:37 ` [61/67] Use scalar_int_mode in the AArch64 port Richard Sandiford
2016-12-09 13:38 ` [63/67] Simplifications after type switch Richard Sandiford
2016-12-09 13:38 ` [62/67] Big machine_mode to scalar_int_mode replacement Richard Sandiford
2016-12-09 13:40 ` [64/67] Add a scalar_mode class Richard Sandiford
2016-12-09 13:40 ` [66/67] Add a scalar_mode_pod class Richard Sandiford
2016-12-09 13:40 ` [65/67] Use scalar_mode in the AArch64 port Richard Sandiford
2016-12-09 13:41 ` [67/67] Add a complex_mode class Richard Sandiford
2016-12-09 18:20 ` [0/67] Add wrapper classes for machine_modes Sandra Loosemore
2017-05-05  7:08 ` Jeff Law [this message]
2017-05-24 14:33   ` Richard Sandiford
2017-06-28 17:27     ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59d78c7c-0a59-ed02-4d90-8a749b328091@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).