On Mittwoch, 27. März 2024 14:34:52 CET Richard Sandiford wrote:
> Matthias Kretz writes:
> > The big issue here is that, IIUC, a user (and the simd library) cannot do
> > the right thing at the moment. There simply isn't enough context
> > information available when parsing the header. I.e.
> >
Matthias Kretz writes:
> Hi Richard,
>
> sorry for not answering sooner. I took action on your mail but failed to also
> give feedback. Now in light of your veto of Srinivas patch I wanted to use
> the
> opportunity to pick this up again.
>
> On Dienstag, 23. Januar 2024 21:57:23 CET Richard
Hi Richard,
sorry for not answering sooner. I took action on your mail but failed to also
give feedback. Now in light of your veto of Srinivas patch I wanted to use the
opportunity to pick this up again.
On Dienstag, 23. Januar 2024 21:57:23 CET Richard Sandiford wrote:
> However, we also
Matthias Kretz writes:
> On Sunday, 10 December 2023 14:29:45 CET Richard Sandiford wrote:
>> Thanks for the patch and sorry for the slow review.
>
> Sorry for my slow reaction. I needed a long vacation. For now I'll focus on
> the design question wrt. multi-arch compilation.
>
>> I can only
On Thursday, 18 January 2024 08:40:48 CET Andrew Pinski wrote:
> On Wed, Jan 17, 2024 at 11:28 PM Matthias Kretz wrote:
> > template
> > struct Point
> > {
> > T x, y, z;
> >
> > T distance_to_origin() {
> > return sqrt(x * x + y * y + z * z);
> > }
> > };
> >
> > Point is one
On Wed, Jan 17, 2024 at 11:28 PM Matthias Kretz wrote:
>
> On Thursday, 4 January 2024 10:10:12 CET Andrew Pinski wrote:
> > I really doubt this would work in the end. Because HW which is 128bits
> > only, can't support -msve-vector-bits=2048 . I am thinking
> > std::experimental::simd is not the
On Sunday, 10 December 2023 14:29:45 CET Richard Sandiford wrote:
> Thanks for the patch and sorry for the slow review.
Sorry for my slow reaction. I needed a long vacation. For now I'll focus on
the design question wrt. multi-arch compilation.
> I can only comment on the usage of SVE, rather
On Thursday, 4 January 2024 10:10:12 CET Andrew Pinski wrote:
> I really doubt this would work in the end. Because HW which is 128bits
> only, can't support -msve-vector-bits=2048 . I am thinking
> std::experimental::simd is not the right way of supporting this.
> Really the route the standard
On Thu, Jan 4, 2024 at 1:03 AM Srinivas Yadav
wrote:
>
>
> Hi,
>
> Thanks a lot for the review. Sorry for the very late reply.
>
> The following are my comments on the feedback.
>
>>
>> The main thing that worries me is:
>>
>> #if _GLIBCXX_SIMD_HAVE_SVE
>> constexpr inline int
Hi,
Thanks a lot for the review. Sorry for the very late reply.
The following are my comments on the feedback.
> The main thing that worries me is:
>
> #if _GLIBCXX_SIMD_HAVE_SVE
> constexpr inline int __sve_vectorized_size_bytes =
> __ARM_FEATURE_SVE_BITS / 8;
> #else
> constexpr
Richard Sandiford writes:
> template
> struct _SveMaskWrapper
> {
> ...
>
> _GLIBCXX_SIMD_INTRINSIC constexpr value_type
> operator[](size_t __i) const
> {
> return _BuiltinSveMaskType::__sve_mask_active_count(
>
Thanks for the patch and sorry for the slow review.
I can only comment on the usage of SVE, rather than on the scaffolding
around it. Hopefully Jonathan or others can comment on the rest.
The main thing that worries me is:
#if _GLIBCXX_SIMD_HAVE_SVE
constexpr inline int
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add simd_sve.h.
* include/Makefile.in: Add simd_sve.h.
* include/experimental/bits/simd.h: Add new SveAbi.
* include/experimental/bits/simd_builtin.h: Use
__no_sve_deduce_t to support existing Neon Abi.
13 matches
Mail list logo
