Move self_logand to the logical_and callable #1959

SadiinsoSnowfall · 2024-09-11T16:06:07Z

No description provided.

SadiinsoSnowfall · 2024-09-30T12:28:54Z

While attempting to fix this callable for the "no simd" configurations, I encountered the following problem:
Say we want to compile the following function:

auto test(logical<short> a, logical<wide<int>> b) {
    return logical_and(a, b);
}

Because of the rules defined by common_logical_t, this should return a logical<wide<int>>, as logical<wide> always takes priority. However, in "no simd" mode, this isn't the case and the logical_and callable attempts to return a logical<wide<short>>, failing to compile. This is because in this mode, the logical_and function is mapped over each element of the b wide value. In doing so, it is passed two logical_scalar_values of type logical<short> and logical<int> at every step. The problem being that in this case, the logical<short> type takes precedence.

The current fix involves using a convert operation before returning the result from the callable. This is a no-op in "simd" mode as the computed type and the returned type do match. A better fix to this problem would be to directly pass the computed type, in this case common_logical_t<T, U> to the map function called in the callable dispatch implementations.

jfalcou · 2024-09-30T14:41:59Z

A better fix to this problem would be to directly pass the computed type, in this case common_logical_t<T, U> to the map function called in the callable dispatch implementations.

This would also improve compile time by not having a convoluted map result computation.
@DenisYaroshevskiy maybe I should fix map outside of this PR then we can update this one and so we don't have the convert laying around.

SadiinsoSnowfall · 2024-10-16T10:01:39Z

waiting on the map2 branch

include/eve/module/core/regular/impl/simd/arm/sve/logical_and.hpp

SadiinsoSnowfall · 2024-11-29T10:00:14Z

After some talking we decided to change the behaviour of common_logical such that the returned type is always a logical of the type of the first of its parameter. This should be mirroring what is done for bitwise callables and fix the problem we were encountering with the callables using common_logical.

This is a breaking change.

jfalcou · 2024-12-05T13:31:53Z

@DenisYaroshevskiy looks like it works. Your opinion is welcome so we can move forward.

DenisYaroshevskiy

I don't like that there is a mess with conversions.
We do two or more conversions per operation.

I would like the logical callable to handle that.

I am ok if that happens with the "smaller logical result type"

include/eve/arch/cpu/logical_wide.hpp

include/eve/module/core/regular/impl/simd/arm/sve/logical_and.hpp

include/eve/module/core/regular/logical_and.hpp

SadiinsoSnowfall · 2024-12-10T16:09:33Z

Note: this PR now also changes the following callables: logical_notand, logical_andnot, logical_or, logical_notor, logical_ornot, logical_xor as they have a dependency on the return type of logical_and and had hardcoded return type in their generic impl.

Also:

changed test.hpp to add cartesian and cartesian_square, previously used in both logical_and and common_value unit tests.
hotfixed operator< in kumi, this fix from Joel will get into kumi mainline.
fixed friends functions to work with the new common_logical behaviour (they will be cleaned up in futures PRs).
changed the logical_xxx unit tests to perform some more cross-type tests and ensure that the new common_logical behaviour is used.
fixed hz_device to make it work with the new common_logical behaviour.

The new behaviour is the following: given two types A and B, both either bool or logical_value, the type returned from common_logical will be:

bool if both A and B are bools
A if B is a bool (or vice versa)
A if it is a simd_value and B isn't.
B if it is a simd_value and A isn't.
If both A and B are simd_values or scalar_values, the return type will be:
- The smallest of the two
- The "most unsigned" one
- The "most integral" one
- The first one (in the case both have the same size, signedness and integral-ness)

DenisYaroshevskiy

quick review

include/eve/arch/cpu/logical.hpp

include/eve/arch/cpu/logical_wide.hpp

include/eve/concept/value.hpp

include/eve/deps/kumi/tuple.hpp

include/eve/detail/function/simd/common/friends.hpp

test/test.hpp

DenisYaroshevskiy · 2024-12-16T12:29:04Z

test/unit/module/core/logical_ops.hpp

+}
+
+template<typename T, typename U>
+using priority_t = eve::as_logical_t<decltype(find_priority_type<T, U>())>;


I'm iffy about this:

It seems like you rewrote a chunk of common_logical a second time and compare them.

Is this a fare description?

I thought that comparing common_logical_t to itself would not be that useful. But without knowing exactly what types we are currently processing, it is difficult to know what should be the output of common_logical_t. If you want I can try to discriminate between floats, signed integrals and unsigned integrals where applicable to make the desired output more clear.

It seems like there is only two usages of priority_t.

Just be explicit about the things you test, don't try to write a function.

Writing a function to validate input is a good idea only if you can somehow write that function in a much easier way than the original.

those two usage are actually used in the test doign a cartesian product of tests over all combo of scalar.
This is not something we can verify easily without missing stuff.

test/unit/module/core/logical_ops.hpp

include/eve/traits/overload/default_behaviors.hpp

include/eve/module/core/regular/is_equal.hpp

DenisYaroshevskiy · 2024-12-16T13:45:19Z

include/eve/module/core/regular/logical_and.hpp

-    { return EVE_DISPATCH_CALL(a, b); }
+    template<typename T, typename U>
+    constexpr EVE_FORCEINLINE common_logical_t<T, U> operator()(T a, U b) const noexcept
+      requires (same_lanes_or_scalar<T, U> && !arithmetic_simd_value<T> && !arithmetic_simd_value<U>)


This is a very weird requirement. Can't you just require relaxed_logical_value on T and U?

See the comment in the file.

what comment.
Like - ok - this is an unacceptable requirement for an interface. We need something reasonable.

This has been updated following our decision to disallow passing non-logical scalar values as parameters to logical_xxx callables.

DenisYaroshevskiy · 2024-12-16T13:48:05Z

include/eve/module/core/regular/logical_and.hpp

-      if constexpr( scalar_value<T> && scalar_value<U> ) return r_t(a && b);
-      else return a && b;
+      if  constexpr (relaxed_logical_scalar_value<T>) return a && b;
+      else                              return bit_cast(a.bits() & b.bits(), as<T>{});


I don't understand this else. You are in cpu right?

Is this like what - logical_value && is_wide_logical? Can you be more explicit about that, this is very confusing.

At least a comment.

I added a comment to clarify.

DenisYaroshevskiy · 2024-12-16T13:48:46Z

include/eve/module/core/regular/logical_notand.hpp

-    { return EVE_DISPATCH_CALL(a, b); }
+    template<typename T, typename U>
+    constexpr EVE_FORCEINLINE common_logical_t<T, U> operator()(T a, U b) const noexcept
+      requires (same_lanes_or_scalar<T, U> && !arithmetic_simd_value<T> && !arithmetic_simd_value<U>)


Same comment here about the requirements.

I updated the answer to the review.

This is still not ok for an interface.

include/eve/module/core/regular/logical_and.hpp

include/eve/concept/scalar.hpp

DenisYaroshevskiy · 2024-12-19T14:38:15Z

include/eve/deps/kumi/tuple.hpp

      }
-      (std::make_index_sequence<sizeof...(Ts)-1>());
-      return res;
+      (std::make_index_sequence<sizeof...(Us)-1>());


What's with this kumi change? This should probably go in upstream first, no? Or do we need to upgrade in lockstep?

upstreal is fixed already as externals CI pass.
This is probably some noise and should be turned back to Ts.

include/eve/detail/hz_device.hpp

include/eve/module/core/regular/is_not_equal.hpp

DenisYaroshevskiy · 2024-12-19T14:47:53Z

include/eve/module/core/regular/logical_and.hpp

-    { return EVE_DISPATCH_CALL(a, b); }
+    template<typename T, typename U>
+    constexpr EVE_FORCEINLINE common_logical_t<T, U> operator()(T a, U b) const noexcept
+      requires (same_lanes_or_scalar<T, U> && !arithmetic_simd_value<T> && !arithmetic_simd_value<U>)


what comment.
Like - ok - this is an unacceptable requirement for an interface. We need something reasonable.

include/eve/module/core/regular/logical_and.hpp

DenisYaroshevskiy · 2024-12-19T14:57:19Z

include/eve/module/core/regular/logical_notand.hpp

-    { return EVE_DISPATCH_CALL(a, b); }
+    template<typename T, typename U>
+    constexpr EVE_FORCEINLINE common_logical_t<T, U> operator()(T a, U b) const noexcept
+      requires (same_lanes_or_scalar<T, U> && !arithmetic_simd_value<T> && !arithmetic_simd_value<U>)


This is still not ok for an interface.

include/eve/module/core/regular/is_less.hpp

include/eve/traits/is_logical.hpp

include/eve/concept/scalar.hpp

include/eve/concept/value.hpp

DenisYaroshevskiy · 2025-01-13T17:14:25Z

include/eve/deps/kumi/tuple.hpp

      auto const order = [&]<typename Index>(Index i)
      {
        auto y_less_x_prev  = rhs[i]  < lhs[i];
        auto x_less_y       = lhs[index_t<Index::value+1>{}] < rhs[index_t<Index::value+1>{}];
-        res                 = res || (x_less_y && !y_less_x_prev);
+        return (x_less_y && !y_less_x_prev);


What's with the kumi changes.

these are for doign a proper fold instead of the bad code from before. This is coming from KUMI head

Would be nice as a separate change, why is this here? (don't bother now)

include/eve/detail/function/simd/common/friends.hpp

include/eve/module/core/regular/logical_and.hpp

include/eve/module/core/regular/logical_or.hpp

include/eve/traits/common_value.hpp

include/eve/traits/overload/default_behaviors.hpp

test/unit/module/core/logical_test.hpp

DenisYaroshevskiy

Almost there!

DenisYaroshevskiy · 2025-01-14T13:56:46Z

include/eve/deps/kumi/tuple.hpp

      auto const order = [&]<typename Index>(Index i)
      {
        auto y_less_x_prev  = rhs[i]  < lhs[i];
        auto x_less_y       = lhs[index_t<Index::value+1>{}] < rhs[index_t<Index::value+1>{}];
-        res                 = res || (x_less_y && !y_less_x_prev);
+        return (x_less_y && !y_less_x_prev);


Would be nice as a separate change, why is this here? (don't bother now)

include/eve/module/core/regular/impl/logical_andnot.hpp

DenisYaroshevskiy · 2025-01-14T14:05:31Z

test/unit/meta/traits/common_logical.cpp

+TTS_CASE("eve::common_logical on boolean x boolean")
+{
+  TTS_TYPE_IS((eve::common_logical_t<bool, bool>), bool);
+};


Nit:

common_logical_t is always simmetrical. Extract a function:

template <typename L, typename R, typename Res> void common_logical_res_test()

And use that one. This way you halve the number of test cases you need to write.

You can also put all "logical/non-logical" common logical stuff in there.

This should be fixed, let me know

test/unit/meta/traits/common_logical.cpp

test/unit/module/core/logical_test.hpp

DenisYaroshevskiy

Please address that french file

include/eve/module/core/detail/generic/ex.toml

SadiinsoSnowfall marked this pull request as draft September 11, 2024 17:27

SadiinsoSnowfall force-pushed the callable-logand branch 4 times, most recently from af4d016 to b0012c1 Compare September 19, 2024 08:28

SadiinsoSnowfall force-pushed the callable-logand branch from da4a721 to e10f67e Compare September 26, 2024 14:03

SadiinsoSnowfall marked this pull request as ready for review September 26, 2024 14:56

SadiinsoSnowfall force-pushed the callable-logand branch from 48d1d7b to 9e3c740 Compare September 30, 2024 09:38

SadiinsoSnowfall marked this pull request as draft October 16, 2024 10:01

DenisYaroshevskiy reviewed Nov 29, 2024

View reviewed changes

include/eve/module/core/regular/impl/simd/arm/sve/logical_and.hpp Outdated Show resolved Hide resolved

SadiinsoSnowfall force-pushed the callable-logand branch 2 times, most recently from 73fbf38 to 6090b71 Compare November 29, 2024 11:08

SadiinsoSnowfall marked this pull request as ready for review December 2, 2024 18:58

jfalcou requested a review from DenisYaroshevskiy December 5, 2024 13:31

DenisYaroshevskiy reviewed Dec 5, 2024

View reviewed changes

SadiinsoSnowfall force-pushed the callable-logand branch from 4f076e5 to c9b000c Compare December 12, 2024 10:01

DenisYaroshevskiy reviewed Dec 12, 2024

View reviewed changes

DenisYaroshevskiy reviewed Dec 16, 2024

View reviewed changes

DenisYaroshevskiy reviewed Dec 19, 2024

View reviewed changes

jfalcou mentioned this pull request Dec 19, 2024

Provide cartesian_product of types<...> jfalcou/tts#104

Open

SadiinsoSnowfall added 4 commits January 10, 2025 20:31

take 1

2f682a1

added backends

8897837

typo

f374c60

allow booleans in common_logical

5cc26d2

SadiinsoSnowfall and others added 10 commits January 10, 2025 20:34

revert useless changes to strict_elementwise_callable

036b8f6

adjusted comment

116353e

refactor AVX512 code

7a79aae

revert is_equal return types

304fb5f

more comments

abe3c1c

preemptive fix for comparison operators

04f750a

Clarify logical_elementwise_callable behavior

fef0f34

review fix

a25aa97

remove logical_elementwise_callable

8fa1ab2

new elementwise_callable behaviour

e54acc0

SadiinsoSnowfall force-pushed the callable-logand branch from 2c46b48 to e54acc0 Compare January 10, 2025 19:34

jfalcou requested changes Jan 11, 2025

View reviewed changes

include/eve/module/core/regular/is_less.hpp Outdated Show resolved Hide resolved

include/eve/traits/is_logical.hpp Outdated Show resolved Hide resolved

SadiinsoSnowfall added 2 commits January 13, 2025 13:14

review fixes

611a5cb

Disallow non-logical scalar values in logical_xxx callables

e7977aa

DenisYaroshevskiy reviewed Jan 13, 2025

View reviewed changes

SadiinsoSnowfall added 7 commits January 13, 2025 19:17

fix doc comments

a1e1605

fix missing newline

58acb0a

Renamed template parameters

a372b95

simplified common_logical

7708997

moved logical_xxx impl to new files

f43fcd9

fixed AVX512 masked rec

d539fdd

remove noise in kumi commit

10ede09

jfalcou approved these changes Jan 14, 2025

View reviewed changes

DenisYaroshevskiy reviewed Jan 14, 2025

View reviewed changes

simplified logical_xxx generic backends

90b8a4b

DenisYaroshevskiy approved these changes Jan 15, 2025

View reviewed changes

include/eve/module/core/detail/generic/ex.toml Outdated Show resolved Hide resolved

adjusted tests and common_logical_t

c2e88d6

SadiinsoSnowfall force-pushed the callable-logand branch from 597475b to c2e88d6 Compare January 15, 2025 14:15

jfalcou merged commit 0e06d4d into main Jan 15, 2025
32 checks passed

jfalcou deleted the callable-logand branch January 15, 2025 16:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Move self_logand to the logical_and callable #1959

Move self_logand to the logical_and callable #1959

SadiinsoSnowfall commented Sep 11, 2024

SadiinsoSnowfall commented Sep 30, 2024

jfalcou commented Sep 30, 2024

SadiinsoSnowfall commented Oct 16, 2024

SadiinsoSnowfall commented Nov 29, 2024

jfalcou commented Dec 5, 2024

DenisYaroshevskiy left a comment

SadiinsoSnowfall commented Dec 10, 2024

DenisYaroshevskiy left a comment

DenisYaroshevskiy Dec 16, 2024

SadiinsoSnowfall Dec 16, 2024

DenisYaroshevskiy Dec 16, 2024

jfalcou Dec 16, 2024

DenisYaroshevskiy Dec 16, 2024

SadiinsoSnowfall Dec 16, 2024

DenisYaroshevskiy Dec 19, 2024

SadiinsoSnowfall Jan 13, 2025

DenisYaroshevskiy Dec 16, 2024

SadiinsoSnowfall Dec 16, 2024

DenisYaroshevskiy Dec 16, 2024

SadiinsoSnowfall Dec 16, 2024

DenisYaroshevskiy Dec 19, 2024

DenisYaroshevskiy Dec 19, 2024

jfalcou Dec 19, 2024

DenisYaroshevskiy Dec 19, 2024

DenisYaroshevskiy Dec 19, 2024

DenisYaroshevskiy Jan 13, 2025

jfalcou Jan 14, 2025

DenisYaroshevskiy Jan 14, 2025

DenisYaroshevskiy left a comment

DenisYaroshevskiy Jan 14, 2025

DenisYaroshevskiy Jan 14, 2025

SadiinsoSnowfall Jan 15, 2025

DenisYaroshevskiy left a comment

Move self_logand to the logical_and callable #1959

Move self_logand to the logical_and callable #1959

Conversation

SadiinsoSnowfall commented Sep 11, 2024

SadiinsoSnowfall commented Sep 30, 2024

jfalcou commented Sep 30, 2024

SadiinsoSnowfall commented Oct 16, 2024

SadiinsoSnowfall commented Nov 29, 2024

jfalcou commented Dec 5, 2024

DenisYaroshevskiy left a comment

Choose a reason for hiding this comment

SadiinsoSnowfall commented Dec 10, 2024

DenisYaroshevskiy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DenisYaroshevskiy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DenisYaroshevskiy left a comment

Choose a reason for hiding this comment