This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] <experimental/simd> Add broadcast constructor of class simd/simd_mask
ClosedPublic

Authored by Joy12138 on Jul 25 2023, 3:41 AM.

Diff Detail

Event Timeline

Joy12138 created this revision.Jul 25 2023, 3:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 25 2023, 3:41 AM
Herald added a subscriber: miyuki. · View Herald Transcript
Joy12138 requested review of this revision.Jul 25 2023, 3:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 25 2023, 3:41 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Joy12138 updated this revision to Diff 544196.Jul 25 2023, 9:34 PM

Update status paper and test

Joy12138 updated this revision to Diff 544197.Jul 25 2023, 9:38 PM

Add newline at end of file

philnik added inline comments.
libcxx/include/experimental/__simd/simd.h
46
libcxx/include/experimental/__simd/utility.h
61–66

Isn't this just is_constructible<__To, __From>?

61–66
libcxx/include/experimental/__simd/vec_ext.h
67
Joy12138 updated this revision to Diff 548051.Aug 7 2023, 8:49 PM

Fix some comments

Joy12138 marked 3 inline comments as done.Aug 7 2023, 9:05 PM
Joy12138 added inline comments.
libcxx/include/experimental/__simd/utility.h
61–66

I'm not sure if the current implementation is the same as is_constructible.
I am also not sure if either of them can meet the requirements of the document: "every possible value of From can be represented with type To".
Do you have any suggestion?

philnik added inline comments.Aug 8 2023, 8:55 AM
libcxx/include/experimental/__simd/utility.h
61–66

I think we have to do something a bit more weird for that. I think we basically have to check that they are integral and that sizeof(From) >= sizeof(To) && is_signed_v<From> == is_signed_v<To>. I'm not sure about floating point types, but there we probably want to do the same % bfloat16 (but that's not relevant for now anyways).

Also, we probably want to make these variable templates instead of structs. Didn't notice that before.

72

I'm pretty sure that unsigned int is indeed unsigned.

Joy12138 updated this revision to Diff 548464.Aug 8 2023, 10:38 PM

Fix some comments

Joy12138 marked an inline comment as done.Aug 8 2023, 10:43 PM
Joy12138 added inline comments.
libcxx/include/experimental/__simd/utility.h
61–66

According to your description, I think what you want is to check for non narrowing conversions. I have learned that brace initialization might ensure non narrowing conversions. What do you think about current implementation?

72

I'm not sure, but have you confused _Up and _Tp?

philnik added inline comments.Aug 9 2023, 10:27 AM
libcxx/include/experimental/__simd/utility.h
61–66

Good thought! This should indeed do the right thing. You're only missing inlines to avoid ODR violations.

72

Oops. Yes, I missed that there is _Tp and _Up. Just ignore the comment.

libcxx/test/std/experimental/simd/simd.class/simd_ctor_broadcast.pass.cpp
62–78

Or am I missing something?

libcxx/test/std/experimental/simd/simd.class/simd_ctor_broadcast.verify.cpp
30 ↗(On Diff #548464)

These tests should be SFINAE checks instead, since the function shall not participate in overload resolution. This construct is not always ill-formed.

libcxx/test/std/experimental/simd/test_utils.h
69
76

Do you know how much is still missing that the old implementation had?

Joy12138 updated this revision to Diff 548853.Aug 9 2023, 7:53 PM
Joy12138 marked 6 inline comments as done.

Fix some comments

Do you know how much is still missing that the old implementation had?

Compare with llvm-project branch main, following implementations are still missing:

  • Default constructor of class simd (simd() = default;)
  • Implicit type conversion constructor of class simd (simd(const simd<_Up, simd_abi::fixed_size<size()>>&))
  • Generator constructor of class simd (simd(_Generator&& __g))
  • Load constructor of class simd (simd(const _Up* __buffer, _Flags))
  • Load and store of class simd (copy_from() and copy_to())
  • Scalar access of class simd (operator [])
  • Operators and functions of class __simd_reference
Joy12138 updated this revision to Diff 549249.Aug 10 2023, 11:03 PM

Add SFINAE tests

Joy12138 added a comment.EditedAug 11 2023, 1:18 AM

The CI errors appear to be related to the type __int128 and __int128 unsigned. I tried these types and it is not supported in GCC implementation (https://godbolt.org/z/EExodWKxE), too. Should we support them? Or where should they be excluded? @philnik

The CI errors appear to be related to the type __int128 and __int128 unsigned. I tried these types and it is not supported in GCC implementation (https://godbolt.org/z/EExodWKxE), too. Should we support them? Or where should they be excluded? @philnik

I don't really see a reason not to support it. A simple test seems to suggest that __int128 works just fine with vector types: https://godbolt.org/z/W9v6T6c8d. So my suspicion is that there is a bug somewhere in your code. It could of course also be a compiler bug, which is supported by the fact that Clang is happy with the code while GCC isn't. Either way, I think we should investigate this.

Joy12138 updated this revision to Diff 549840.Aug 14 2023, 2:25 AM

Try to fix __int128

It seems is_integral not working correctly with int128 and unsigned int128. https://godbolt.org/z/c4E5T7zc9

I add specializations for __can_broadcast with int128 and unsigned int128. It may fix tests now. Is it OK? Or should we fix is_integral?

It seems is_integral not working correctly with int128 and unsigned int128. https://godbolt.org/z/c4E5T7zc9

I add specializations for __can_broadcast with int128 and unsigned int128. It may fix tests now. Is it OK? Or should we fix is_integral?

is_integral is fine: https://godbolt.org/z/bdof3Krvo. It also looks like your change didn't actually fix the problem.

I attempted to debug the error in the CI. When _Tp is __int128 unsigned, in the __broadcast function within the vec_ext.h header, the value of __result.__get(0) printed just before the return statement is correct. However, after the return, in the broadcast constructor within the simd.h header, the higher 64 bits of the value printed as _Impl::__broadcast(static_cast<value_type>(__v)).__get(0) become garbled data. It seems that the value is being truncated upon return.

Strangely, this issue only reproduces in the current libcxx CI - GCC 12 / C++latest environment. I have been unable to reproduce this issue in any other environment.

Currently, I am unsure how to go about fixing this issue. Do you have any suggestions? @philnik

Joy12138 updated this revision to Diff 553841.Aug 27 2023, 10:47 PM

Remove incorrect fixes

Joy12138 updated this revision to Diff 553842.Aug 27 2023, 10:53 PM

Remove incorrect fixes

I attempted to debug the error in the CI. When _Tp is __int128 unsigned, in the __broadcast function within the vec_ext.h header, the value of __result.__get(0) printed just before the return statement is correct. However, after the return, in the broadcast constructor within the simd.h header, the higher 64 bits of the value printed as _Impl::__broadcast(static_cast<value_type>(__v)).__get(0) become garbled data. It seems that the value is being truncated upon return.

Strangely, this issue only reproduces in the current libcxx CI - GCC 12 / C++latest environment. I have been unable to reproduce this issue in any other environment.

Currently, I am unsure how to go about fixing this issue. Do you have any suggestions? @philnik

Our minimum supported GCC version recently changed to GCC-13. Can you rebase this patch? That will pick up GCC-13 in the CI.

I think we should try to rebase, as @Mordante suggested. If that doesn't help I'd just go for // XFAIL: gcc-13ing the tests for now. If the bug still exists in GCC 13 it would be great if you could try to get a small reproducer and file a bug against GCC.

Joy12138 updated this revision to Diff 555649.EditedSep 3 2023, 8:57 PM

Temporarily add // XFAIL: gcc-13

philnik accepted this revision.Sep 11 2023, 11:04 AM
This revision is now accepted and ready to land.Sep 11 2023, 11:04 AM
This revision was landed with ongoing or failed builds.Sep 11 2023, 8:42 PM
This revision was automatically updated to reflect the committed changes.

Thank you very much for your reminder. I tried to fix this issue in revision https://reviews.llvm.org/D159509 and land this patch after CI passed.