[RFC][POC] Suggest re-design of compile-time properties extension

[aelovikov-intel]

This is based on @rolandschulz 's #13776, with lots of help from both @rolandschulz and @tahonermann in offline chats.

This is a proof of concept on how the extension can be changed. The purpose of this PR is to start discussion on

1. If the proposed redesign is acceptable/desirable
2. If so, how should we implement it? Should we have a single PR that updates the extension, implementation and uses all at once? If yes, can we do that outside of the major release?

I plan on drafting the changes to the extension later on once the implementation prototype is closer to finalization.

As of now this PR adds new implementation and sycl::ext::oneapi::experimental::new_properties namespace and switches group_load_store extension to use that instead of old properties. I'll try to port something using runtime property later and will update the PR after that.

[rolandschulz]

I think here we want to dragonize separately if the repeating is because there are conflicting sort_keys (sort_key is same but property_ty isn't).

[rolandschulz]

Also does this assert actual give a reasonable diagnostic in case of repeating properties? I had to add a special base case

llvm/sycl/include/sycl/ext/oneapi/properties/properties.hpp

Line 60 in 9b643a3

// base case is only for invalid cases to suppress compiler errors about base

to get only the static assert. Otherwise the compiler would complain about duplicate base types and wouldn't even get to the assert.

BTW: We'll need unit tests for the expected errors.

[aelovikov-intel]

Agree with negative unit test. Not sure about repeating sort_key. I assume you're talking about the case when two distinct unrelated properties happened to have the same sort key by mistake. However, that is undistinguishable from a valid scenario when compile-time properties that carry extra information other than their mere presence do share the sort_key. For example,

enum class data_placement { blocked, striped };
template <data_placement placement>
struct data_placement_property
    : detail::property_base<data_placement_property<placement>,
                            struct data_placement_property_key> {
  static constexpr mock_property_sort_key_t sort_key = 3;
  static constexpr bool is_blocked() {
    return placement == data_placement::blocked;
  }
};

We don't want to allow properties{data_placement_property<blocked>{}, data_placement_property<striped>{}} and we catch that because they have the same sort key, but the fact that they do have it is by design and is intentional.

[aelovikov-intel]

I had to add a special base case

Thanks! I wouldn't have guessed how to make that work on my own...

[rolandschulz]

We can distinguish properties{data_placement_property<blocked>{}, data_placement_property<striped>{}} from properties{prop_a{}, prop_b{}} where propb_a and prob_b have the same sort-key by mistake. While in both cases the property type is different and the sort key is the same, the first case has the same property key type and the 2nd has two different property key types. This difference allows us to issue different diagnostic.

[aelovikov-intel]

I think latest revision addresses this thread, please "resolve conversation" if you agree.

[aelovikov-intel]

I'm not sure if const ct_prop<42> instead of prop<42> is an issue, and if it is then I don't know how to address it.