-
Notifications
You must be signed in to change notification settings - Fork 107
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
[oneDPL] Declare predefined dpcpp_default
policy as const
#554
[oneDPL] Declare predefined dpcpp_default
policy as const
#554
Conversation
…t as inline const + {};
@akukanov Why |
dpcpp_default
and dpcpp fpga
policies as const
dpcpp_default
policy as const
There is neither enough implementation experience nor enough demand to justify adding special FPGA policies to the oneDPL specification. |
…the way dpcpp_default is constructed should not be prescribed in the specification.
Lets mark the title of this PR with [oneDPL] to match the convention established so far. |
dpcpp_default
policy as const
dpcpp_default
policy as const
Done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
(Edited by @akukanov)
This patch fixes what we consider to be a bug in the oneDPL specification, namely - the predefined
dpcpp_default
execution policy not beingconst
.Since all explicitly specified member functions of the
device_policy
class areconst
, a mutable policy object differs from a non-mutable (const
) policy object in two ways:Neither of the above is an appropriate modification for
dpcpp_default
, potentially changing its semantics as a predefined policy associated with the default SYCL device. The possibility of such modifications was previously overlooked and deserves to be fixed.The change will not impact the ability to pass
dpcpp_default
to oneDPL algorithms, to obtain its associated queue, and to copy or rebind the policy (including using it as the argument to themake_device_policy
function), which constitute the vast majority of its usages in application codes. Codes that might be broken by the change either do not properly handle anyconst
instances of the class or depend on the possibility to modifydpcpp_default
, which we do not consider as a proper use and want to prevent. In the latter case, a workaround can be to create a copy ofdpcpp_default
and use that instead.