From: Matthias Kretz <m.kretz@gsi.de>
To: <gcc-patches@gcc.gnu.org>, Jason Merrill <jason@redhat.com>
Cc: <libstdc++@gcc.gnu.org>, David Malcolm <dmalcolm@redhat.com>,
Jonathan Wakely <jwakely@redhat.com>
Subject: Re: [PATCH] Add gnu::diagnose_as attribute
Date: Fri, 11 Jun 2021 12:01:51 +0200 [thread overview]
Message-ID: <2132675.qKCeTcHjAi@excalibur> (raw)
In-Reply-To: <cdfc040a-4195-d453-b01e-c1eb7ed33e3a@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]
How can we make progress here? I could try to produce some "Tony Tables" of
diagnostic output of my modified stdx::simd. I believe it's a major
productivity boost to see abbreviated / "obfuscated" diagnostics *out-of-the
box* (with the possibility to opt-out). Actually, it already *is* a
productivity boost to me. Understanding diagnostics has improved from
"1. ooof, I'm not going to read this, let me rather guess what the issue was
2. sh** I have to read it
3. several minutes later: I finally found the five words to understand the
problem; I could use a break"
to
"1. right, let me check that"
For reference I'll attach my stdx::simd diagnose_as patch.
We could also talk about extending the feature to provide more information
about the diagnose_as substition. E.g. print a list of all diagnose_as
substitutions, which were used, at the end of the output stream. Or simpler,
print "note: some identifiers were simplified, use -fno-diagnostics-use-
aliases to see their real names".
On Tuesday, 1 June 2021 21:12:18 CEST Jason Merrill wrote:
> > Right, but then two of my design goals can't be met:
> >
> > 1. Diagnostics have an improved signal-to-noise ratio out of the box.
> >
> > 2. We can use replacement names that are not valid identifiers.
>
> This is the basic disconnect: I think that these goals are
> contradictory, and that replacement names that are not valid identifiers
> will just confuse users that don't know about them.
>
> If a user sees stdx::foo in a diagnostic and then tries to refer to
> stdx::foo and gets an error, the diagnostic is not more helpful than one
> that uses the fully qualified name.
>
> Jonathan, David, any thoughts on this issue?
--
──────────────────────────────────────────────────────────────────────────
Dr. Matthias Kretz https://mattkretz.github.io
GSI Helmholtz Centre for Heavy Ion Research https://gsi.de
std::experimental::simd https://github.com/VcDevel/std-simd
──────────────────────────────────────────────────────────────────────────
[-- Attachment #2: 0001-libstdc-Decrease-noise-in-diagnostics-via-diagnose_a.patch --]
[-- Type: text/x-patch, Size: 3454 bytes --]
diff --git a/libstdc++-v3/include/experimental/bits/simd.h b/libstdc++-v3/include/experimental/bits/simd.h
index 43331134301..8e0cceff860 100644
--- a/libstdc++-v3/include/experimental/bits/simd.h
+++ b/libstdc++-v3/include/experimental/bits/simd.h
@@ -80,13 +80,13 @@ using __m512d [[__gnu__::__vector_size__(64)]] = double;
using __m512i [[__gnu__::__vector_size__(64)]] = long long;
#endif
-namespace simd_abi {
+namespace simd_abi [[__gnu__::__diagnose_as__("simd_abi")]] {
// simd_abi forward declarations {{{
// implementation details:
-struct _Scalar;
+ struct [[__gnu__::__diagnose_as__("scalar")]] _Scalar;
template <int _Np>
- struct _Fixed;
+ struct [[__gnu__::__diagnose_as__("fixed_size")]] _Fixed;
// There are two major ABIs that appear on different architectures.
// Both have non-boolean values packed into an N Byte register
@@ -105,28 +105,11 @@ template <int _UsedBytes>
template <int _UsedBytes>
struct _VecBltnBtmsk;
-template <typename _Tp, int _Np>
- using _VecN = _VecBuiltin<sizeof(_Tp) * _Np>;
-
-template <int _UsedBytes = 16>
- using _Sse = _VecBuiltin<_UsedBytes>;
-
-template <int _UsedBytes = 32>
- using _Avx = _VecBuiltin<_UsedBytes>;
-
-template <int _UsedBytes = 64>
- using _Avx512 = _VecBltnBtmsk<_UsedBytes>;
-
-template <int _UsedBytes = 16>
- using _Neon = _VecBuiltin<_UsedBytes>;
-
-// implementation-defined:
-using __sse = _Sse<>;
-using __avx = _Avx<>;
-using __avx512 = _Avx512<>;
-using __neon = _Neon<>;
-using __neon128 = _Neon<16>;
-using __neon64 = _Neon<8>;
+#if defined __i386__ || defined __x86_64__
+using __sse [[__gnu__::__diagnose_as__("[SSE]")]] = _VecBuiltin<16>;
+using __avx [[__gnu__::__diagnose_as__("[AVX]")]] = _VecBuiltin<32>;
+using __avx512 [[__gnu__::__diagnose_as__("[AVX512]")]] = _VecBltnBtmsk<64>;
+#endif
// standard:
template <typename _Tp, size_t _Np, typename...>
@@ -364,7 +347,7 @@ namespace __detail
* users link TUs compiled with different flags. This is especially important
* for using simd in libraries.
*/
- using __odr_helper
+ using __odr_helper [[__gnu__::__diagnose_as__("[ODR helper]")]]
= conditional_t<__machine_flags() == 0, _OdrEnforcer,
_MachineFlagsTemplate<__machine_flags(), __floating_point_flags()>>;
@@ -689,7 +672,7 @@ template <typename _Abi>
__is_avx512_abi()
{
constexpr auto _Bytes = __abi_bytes_v<_Abi>;
- return _Bytes <= 64 && is_same_v<simd_abi::_Avx512<_Bytes>, _Abi>;
+ return _Bytes <= 64 && is_same_v<simd_abi::_VecBltnBtmsk<_Bytes>, _Abi>;
}
// }}}
diff --git a/libstdc++-v3/include/experimental/bits/simd_detail.h b/libstdc++-v3/include/experimental/bits/simd_detail.h
index 78ad33f74e4..1f127cd0d52 100644
--- a/libstdc++-v3/include/experimental/bits/simd_detail.h
+++ b/libstdc++-v3/include/experimental/bits/simd_detail.h
@@ -36,7 +36,7 @@
{ \
_GLIBCXX_BEGIN_NAMESPACE_VERSION \
namespace experimental { \
- inline namespace parallelism_v2 {
+ inline namespace parallelism_v2 [[__gnu__::__diagnose_as__("std\u2093")]] {
#define _GLIBCXX_SIMD_END_NAMESPACE \
} \
} \
next prev parent reply other threads:[~2021-06-11 10:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-23 15:16 [RFC] " Matthias Kretz
2021-04-27 9:46 ` Jonathan Wakely
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 [this message]
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=2132675.qKCeTcHjAi@excalibur \
--to=m.kretz@gsi.de \
--cc=dmalcolm@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=jwakely@redhat.com \
--cc=libstdc++@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).