public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Matthias Kretz <m.kretz@gsi.de>
Cc: libstdc++@gcc.gnu.org
Subject: Re: [RFC] Add gnu::diagnose_as attribute
Date: Tue, 27 Apr 2021 10:46:48 +0100	[thread overview]
Message-ID: <20210427094648.GL3008@redhat.com> (raw)
In-Reply-To: <14205410.xuKvIAzr1H@excalibur>

On 23/04/21 17:16 +0200, Matthias Kretz wrote:
>Hi,
>
>before requesting comments on the implementation of this patch, I'd like to
>know if there's interest in making use of it at all.
>
>In a nutshell, this solves the problem of bad signal-to-noise ratio with TS
>implementations and potentially implementation-internal types.
>
>I've been using the diagnose_as attribute on my parallelism_v2 simd
>implementation for two months now, and it significantly improved my
>productivity. Like this:
>
>namespace std _GLIBCXX_VISIBILITY(default)
>{
>  _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  namespace experimental
>  {
>    inline namespace parallelism_v2 [[__gnu__::__diagnose_as__("stdₓ")]]
>    {
>      namespace simd_abi [[__gnu__::__diagnose_as__("simd_abi")]]
>      {
>        struct [[__gnu__::__diagnose_as__("scalar")]] _Scalar;
>        using scalar = _Scalar;
>
>        template <int _Np>
>          struct [[__gnu__::__diagnose_as__("fixed_size")]] _Fixed;
>        template <int _Np>
>          using fixed_size = _Fixed<_Np>;
>[...]
>
>Effects:
>1. __PRETTY_FUNCTION__ in my test output:
>
>   PASS: void invoke_test(int) [with V = stdₓ::simd<double,
>simd_abi::_VecBuiltin<16> >; <template-parameter-1-2> = stdₓ::simd<double,
>simd_abi::_VecBuiltin<16> >]
>
>   instead of
>
>   PASS: void invoke_test(int) [with V =
>std::experimental::parallelism_v2::simd<double,
>std::experimental::parallelism_v2::simd_abi::_VecBuiltin<16> >; <template-
>parameter-1-2> = std::experimental::parallelism_v2::simd<double,
>std::experimental::parallelism_v2::simd_abi::_VecBuiltin<16> >]
>
>2. Error messages:
>
>   required from 'static constexpr stdₓ::_SimdWrapper<_Tp, _Np>
>stdₓ::_SimdImplBuiltin<_Abi, <template-parameter-1-2>
>>::_S_fma(stdₓ::_SimdWrapper<_Tp, _Np>, stdₓ::_SimdWrapper<_Tp, _Np>,
>stdₓ::_SimdWrapper<_Tp, _Np>) [with _Tp = double; long unsigned int _Np = 2;
>_Abi = simd_abi::_VecBuiltin<16>; <template-parameter-1-2> =
>stdₓ::__detail::_MachineFlagsTemplate<31, 9>]'
>
>   instead of
>
>   required from 'static constexpr
>std::experimental::parallelism_v2::_SimdWrapper<_Tp, _Np>
>std::experimental::parallelism_v2::_SimdImplBuiltin<_Abi, <template-
>parameter-1-2> >::_S_fma(std::experimental::parallelism_v2::_SimdWrapper<_Tp,
>_Np>, std::experimental::parallelism_v2::_SimdWrapper<_Tp, _Np>,
>std::experimental::parallelism_v2::_SimdWrapper<_Tp, _Np>) [with _Tp = double;
>long unsigned int _Np = 2; _Abi =
>std::experimental::parallelism_v2::simd_abi::_VecBuiltin<16>; <template-
>parameter-1-2> =
>std::experimental::parallelism_v2::__detail::_MachineFlagsTemplate<31, 9>]'
>
>
>Since the main user of the attribute would be the standard library (I
>believe), this patch only makes sense to pursue if there's interest in using
>it in libstdc++. I'd like to use it for stdₓ::simd. Would you accept such a

I think it's a great idea and would like to use it for all the TS
implementations where there is some inline namespace that the user
doesn't care about. std::experimental::fundamentals_v1:: would be much
better as just std::experimental::, or something like std::[LFTS]::.

My gut feeling is that something that isn't valid C++ syntax would
make it clear you can't just copy&paste the qualified-name from the
diagnostics to the code, so some identifier in square brackets would
work. But I'm willing to be persuaded that doesn't matter.

>patch? I guess using unicode in the alias name would not be acceptable,
>though?

I'm not wild about the UTF-8 characters, but we could define a macro
for the attribute, and have:

#if _GLIBCXX_SHOW_FANCY_NAMES
# define _GLIBCXX_STDX [[__gnu__::__diagnose_as__ ("std\u2093")]]
#else
# define _GLIBCXX_STDX [[__gnu__::__diagnose_as__ ("std::[exp]")]]
#endif

(The universal character name ensures the header can still be used
with -finput-charset=ascii and similar, but still prints "stdₓ" in the
diagnostic.)



  reply	other threads:[~2021-04-27  9:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-23 15:16 Matthias Kretz
2021-04-27  9:46 ` Jonathan Wakely [this message]
2021-05-04 11:13   ` [PATCH] " Matthias Kretz
2021-05-04 13:34     ` David Malcolm
2021-05-04 14:23       ` Matthias Kretz
2021-05-04 14:32         ` Matthias Kretz
2021-05-04 19:00         ` David Malcolm
2021-05-04 19:22           ` Matthias Kretz
2021-05-14 16:05     ` Martin Sebor
2021-05-26 21:33       ` Matthias Kretz
2021-05-27 17:39     ` Jason Merrill
2021-05-27 18:54       ` Matthias Kretz
2021-05-27 21:15         ` Jason Merrill
2021-05-27 22:07           ` Matthias Kretz
2021-05-28  3:05             ` Jason Merrill
2021-05-28  7:42               ` Matthias Kretz
2021-06-01 19:12                 ` Jason Merrill
2021-06-01 21:01                   ` Matthias Kretz
2021-06-11 10:01                   ` Matthias Kretz
2021-06-15 15:51                     ` Jason Merrill
2021-06-15 20:56                       ` Matthias Kretz
2021-06-16  0:48                         ` Jason Merrill
2021-06-22  7:30                           ` Matthias Kretz
2021-06-22 19:52                             ` Jason Merrill
2021-06-22 20:01                               ` Matthias Kretz
2021-06-22 20:12                                 ` Jason Merrill

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=20210427094648.GL3008@redhat.com \
    --to=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=m.kretz@gsi.de \
    /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).