-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify behavior when wrong property is passed #643
Comments
I want to add one more thing to consider against option #2. What to return when someone sends incorrect runtime property and we ignore it stating that it is UB but then call get/has_property with it? Then it seems to be declared as UB also but in reality it will work and user will never know that the scenario is incorrect. |
Third option, which I think is probably most inline with what is happening with current implementations: If property is for a different API and meaningless for the one it is passed to, define that it will be ignored (not UB). This would allow reusing property lists, i.e. something like the following:
which could perhaps be convenient to specify the desired behavior of the program more globally. If we don't want to support that use case, then I think there is little value in having a generic |
It seems wrong to me to provide a guarantee that an incompatible property is ignored. I think this would most likely indicate a bug in the application, and I think it should be valid to diagnose an error. Commenting on this last part, though. In fact, our compile-time property extension would provide the behavior you are suggesting, with a separate property list types. With compile-time properties. the property list type is a template that depends on the properties that it contains. As a result, you can diagnose incompatible properties at compile time. |
Do you error already when the property list is constructed with properties for multiple APIs, or only when you use the property list in an API? |
No, we do not error in this situation, and I'm not proposing that we do. I think it should be legal to construct a property list with any combination of properties, even if that combination cannot be passed to any of the SYCL APIs. As you suggest, I only think we should diagnose an error if the property list is passed to an API and the list contains a property that is incompatible with that API.
I definitely think the existing |
What is the use case for being able to construct property lists of arbitrary properties, if you then cannot pass those to APIs? So my feeling is that we should either:
|
Adding separate property list types is out of scope for SYCL 2020. Given that we have a single Why are you opposed to throwing an exception at the point when we can diagnose an error? |
Agreed.
At the very least, I suppose we could throw an exception at runtime when the property list constructor runs. But there would be some runtime overhead due to having to runtime-type-check the properties.
I'm not super hard against it, I'm just trying to figure out what the use cases are that we think are important for property list, and where we want to go with property list in the future. In that context, depending on what we decide regarding the use cases, I'm not sure it's the best solution. For example, if we think that property list of arbitrary, incompatible types is important, we should ignore incompatible properties in our APIs. If we say that it's crucial that such a case is prevented, we should do it as early as possible. |
I think this would be hard because some properties are valid for more than one SYCL API. In any case, this wouldn't diagnose the case when you created a property list with consistent properties that was passed an an incompatible API. Consider the common case of a property list with one property. Obviously, that one property is consistent with itself, so the property list constructor won't diagnose an error. However, the application could still pass that property list to an API which doesn't accept that property. |
It seems like discussion of a third option has petered out, so I think we are back to the two options I proposed at the beginning:
In both cases, it would be valid for the implementation to throw an exception from the constructor if the property list contains incompatible properties. Therefore, the only difference is whether the exception is mandated. I have a slight preference for (2) only because it will allow the implementation to skip the error check in cases where it is on the hot path for launching a kernel. (For example, this might be the case for an I think the problem will go away when we adopt compile-time properties because then we will be able to diagnose incompatible properties at compile time (with no runtime overhead). |
I vote for 1. throwing |
This question came from our development team.
The specification does not say what should happen if an incompatible property is passed to an API that takes a
property_list
. Here is a list of the APIs that take aproperty_list
. I don't think any of them currently specify the behavior when an incompatible property is passed.context
constructorsqueue
constructorsbuffer
constructorsunsampled_image
constructorssampled_image
constructorsaccessor
constructorshost_accessor
constructorslocal_accessor
constructorsunsampled_image_accessor
constructorshost_unsampled_image_accessor
constructorssampled_image_accessor
constructorshost_sampled_image_accessor
constructorsusm_allocator
constructorsmalloc_device
,aligned_alloc_device
malloc_host
,aligned_alloc_host
malloc_shared
,aligned_alloc_shared
sycl::malloc
,aligned_alloc
reduction
functionscompile
,link
,build
(kernel bundle)stream
constructorsI think there are two reasonable options:
errc::invalid
in this case.The text was updated successfully, but these errors were encountered: