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.)
next prev parent 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).