public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: David Malcolm <dmalcolm@redhat.com>
Cc: <gcc-patches@gcc.gnu.org>
Subject: Re: [7/67] Add scalar_float_mode
Date: Fri, 09 Dec 2016 14:30:00 -0000	[thread overview]
Message-ID: <877f79dvks.fsf@e105548-lin.cambridge.arm.com> (raw)
In-Reply-To: <1481293184.16607.25.camel@redhat.com> (David Malcolm's message	of "Fri, 9 Dec 2016 09:19:44 -0500")

David Malcolm <dmalcolm@redhat.com> writes:
> On Fri, 2016-12-09 at 12:56 +0000, Richard Sandiford wrote:
>> This patch adds a scalar_float_mode class, which wraps a mode enum
>> that is known to satisfy SCALAR_FLOAT_MODE_P.  Things like "SFmode"
>> now give a scalar_float_mode object instead of a machine_mode.
>> This in turn needs a change to the real.h format_helper, so that
>> it can accept both machine_modes and scalar_float_modes.
>
> [...]
>
>> diff --git a/gcc/machmode.h b/gcc/machmode.h
>> index 44a8ad4..996f991 100644
>> --- a/gcc/machmode.h
>> +++ b/gcc/machmode.h
>> @@ -29,6 +29,16 @@ extern const unsigned short
>> mode_unit_precision[NUM_MACHINE_MODES];
>>  extern const unsigned char mode_wider[NUM_MACHINE_MODES];
>>  extern const unsigned char mode_2xwider[NUM_MACHINE_MODES];
>>  
>> +/* Allow direct conversion of enums to specific mode classes only
>> +   when USE_ENUM_MODES is defined.  This is only intended for use
>> +   by gencondmd, so that it can tell more easily when .md conditions
>> +   are always false.  */
>> +#ifdef USE_ENUM_MODES
>> +#define PROTECT_ENUM_CONVERSION public
>> +#else
>> +#define PROTECT_ENUM_CONVERSION protected
>> +#endif
>> +
>>  /* Get the name of mode MODE as a string.  */
>>  
>>  extern const char * const mode_name[NUM_MACHINE_MODES];
>> @@ -237,6 +247,85 @@ opt_mode<T>::exists (U *mode) const
>>    return false;
>>  }
>>  
>> +/* Return true if mode M has type T.  */
>> +
>> +template<typename T>
>> +inline bool
>> +is_a (machine_mode_enum m)
>> +{
>> +  return T::includes_p (m);
>> +}
>> +
>> +/* Assert that mode M has type T, and return it in that form.  */
>> +
>> +template<typename T>
>> +inline T
>> +as_a (machine_mode_enum m)
>> +{
>> +  gcc_checking_assert (T::includes_p (m));
>> +  return T::from_int (m);
>> +}
>> +
>> +/* Convert M to an opt_mode<T>.  */
>> +
>> +template<typename T>
>> +inline opt_mode<T>
>> +dyn_cast (machine_mode_enum m)
>> +{
>> +  if (T::includes_p (m))
>> +    return T::from_int (m);
>> +  return opt_mode<T> ();
>> +}
>> +
>> +/* Return true if mode M has type T, storing it as a T in *RESULT
>> +   if so.  */
>> +
>> +template<typename T, typename U>
>> +inline bool
>> +is_a (machine_mode_enum m, U *result)
>> +{
>> +  if (T::includes_p (m))
>> +    {
>> +      *result = T::from_int (m);
>> +      return true;
>> +    }
>> +  return false;
>> +}
>> +
>> +/* Represents a machine mode that is known to be a
>> SCALAR_FLOAT_MODE_P.  */
>> +class scalar_float_mode
>
> Should this be a subclass of machine_mode?  Or does this lead to name
> clashes? (e.g. for "from_int")
>
> (Similar questions for the other more specialized wrapper classes; it
> looks like you have a set of independent wrapper classes around the
> machine_mode_enum, without using inheritance, with a trip through the
> enum needed to convert between wrappers)

Making it a subclass would be the natural thing to do if the class
actually defined the mode (and if we for example used pointers to
the definitions to represent the mode).  With wrappers it's kind-of
the "wrong way round" though: having scalar_int_mode a subclass of
machine_mode would allow things like:

  void foo (machine_mode *x) { *x = SFmode; }
  void bar () { scalar_int_mode y; foo (&y); ... }

and so isn't type-safe.

>> +{
>> +public:
>> +  ALWAYS_INLINE scalar_float_mode () {}
>> +  ALWAYS_INLINE operator machine_mode_enum () const { return m_mode;
>> }
>> +
>> +  static bool includes_p (machine_mode_enum);
>> +  static scalar_float_mode from_int (int i);
>> +
>> +PROTECT_ENUM_CONVERSION:
>> +  ALWAYS_INLINE scalar_float_mode (machine_mode_enum m) : m_mode (m)
>> {}
>
> Should this ctor have some kind of:
>   gcc_checking_assert (SCALAR_FLOAT_MODE_P (m));
> or somesuch?  (or does that slow down the debug build too much?)

The idea was to have the asserts in as_a <> calls instead, which is
the point at which forcible conversion occurs.  These routines are for
cases where we've already done the check or know due to static type
checking that a check isn't needed.

>> +
>> +protected:
>> +  machine_mode_enum m_mode;
>> +};
>> +
>> +/* Return true if M is a scalar_float_mode.  */
>> +
>> +inline bool
>> +scalar_float_mode::includes_p (machine_mode_enum m)
>> +{
>> +  return SCALAR_FLOAT_MODE_P (m);
>> +}
>> +
>> +/* Return M as a scalar_float_mode.  This function should only be
>> used by
>> +   utility functions; general code should use as_a<T> instead.  */
>> +
>> +ALWAYS_INLINE scalar_float_mode
>> +scalar_float_mode::from_int (int i)
>> +{
>> +  return machine_mode_enum (i);
>> +}
>
> ...or put an assertion in here?  (I *think* it's the only public
> function that can (implicitly) call the ctor without checking the
> invariant)

Same idea here: this should only be called when no check is needed,
and like you say shouldn't have an assert for speed reasons.  The
number of callers to from_int is small and so it's relatively easy
to check that the calls are safe.

> Hope this is constructive

Yeah, definitely :-)

Thanks,
Richard

  reply	other threads:[~2016-12-09 14:30 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-09 12:48 [0/67] Add wrapper classes for machine_modes 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 ` [7/67] Add scalar_float_mode Richard Sandiford
2016-12-09 14:19   ` David Malcolm
2016-12-09 14:30     ` Richard Sandiford [this message]
2016-12-09 12:57 ` [8/67] Simplify gen_trunc/extend_conv_libfunc 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 ` [12/67] Use opt_scalar_float_mode when iterating over float modes Richard Sandiford
2016-12-09 13:00 ` [11/67] Add a float_mode_for_size helper function 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 ` [21/67] Replace SCALAR_INT_MODE_P checks with is_a <scalar_int_mode> Richard Sandiford
2016-12-09 13:07 ` [22/67] Replace !VECTOR_MODE_P " Richard Sandiford
2016-12-09 13:08 ` [23/67] Replace != VOIDmode 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: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 ` [30/67] Use scalar_int_mode for doubleword splits Richard Sandiford
2016-12-09 13:12 ` [29/67] Make some *_loc_descriptor helpers take scalar_int_mode Richard Sandiford
2016-12-09 13:13 ` [31/67] Use scalar_int_mode for move2add Richard Sandiford
2016-12-09 13:14 ` [33/67] Add a NARROWEST_INT_MODE macro 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:15 ` [34/67] Add a SCALAR_INT_TYPE_MODE macro Richard Sandiford
2016-12-09 13:16 ` [36/67] Use scalar_int_mode in the RTL iv routines Richard Sandiford
2016-12-09 13:16 ` [35/67] Add uses of as_a <scalar_int_mode> 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:17 ` [37/67] Use scalar_int_mode when emitting cstores 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 ` [41/67] Split scalar integer handling out of force_to_mode Richard Sandiford
2016-12-09 13:20 ` [42/67] Use scalar_int_mode in simplify_shift_const_1 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 ` [53/67] Pass a mode to const_scalar_mask_from_tree Richard Sandiford
2016-12-09 13:31 ` [54/67] Add explicit int checks for alternative optab implementations Richard Sandiford
2016-12-09 13:33 ` [55/67] Use scalar_int_mode in simplify_const_unary_operation 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: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 ` [65/67] Use scalar_mode in the AArch64 port Richard Sandiford
2016-12-09 13:40 ` [66/67] Add a scalar_mode_pod class 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
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=877f79dvks.fsf@e105548-lin.cambridge.arm.com \
    --to=richard.sandiford@arm.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).