Details
- Reviewers
philnik - Group Reviewers
Restricted Project - Commits
- rGed29f275bfc0: [libcxx] <experimental/simd> Add broadcast constructor of class simd/simd_mask
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/include/experimental/__simd/utility.h | ||
---|---|---|
61–66 | I'm not sure if the current implementation is the same as is_constructible. |
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. |
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? |
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 |
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
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.
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
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.
This broke the CI, see https://buildkite.com/llvm-project/libcxx-ci/builds/29619#018a8977-1827-49a1-a154-5d960fc5da5e. Can you please fix or revert?
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.