[Mesa-dev] [PATCH 5/5] clover/llvm: Make __OPENCL_VERSION__ dynamic
Aaron Watry
awatry at gmail.com
Tue Jul 25 02:41:24 UTC 2017
On Sat, Jul 22, 2017 at 2:59 PM, Jan Vesely <jan.vesely at rutgers.edu> wrote:
> On Fri, 2017-07-21 at 23:19 -0500, Aaron Watry wrote:
>> Base it on the active language version
>>
>> Signed-off-by: Aaron Watry <awatry at gmail.com>
>> ---
>> src/gallium/state_trackers/clover/llvm/invocation.cpp | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp b/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> index 92d72e5b73..b562babf91 100644
>> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> @@ -202,7 +202,8 @@ namespace {
>> c.getPreprocessorOpts().Includes.push_back("clc/clc.h");
>>
>> // Add definition for the OpenCL version
>> - c.getPreprocessorOpts().addMacroDef("__OPENCL_VERSION__=110");
>> + c.getPreprocessorOpts().addMacroDef("__OPENCL_VERSION__=" +
>> + std::to_string(c.getLangOpts().OpenCLVersion));
>
> similar to previous patch. This should use device OCL version rather
> than language version. Moreover, I don't think value of this macro
> should be impacted by -cl-std= build parameter.
> __OPENCL_C_VERSION__ was added for to fill the gap of both above
> behaviours.
Fair enough.
I'll respin the series, taking this into account along with Pierre's
feedback. Having code in invocation.cpp that needs both device CL/CLC
version means we'll be plumbing either the device CL version and
device CLC version down into invocation.cpp, or possibly just passing
the itself device down.
I'm leaning towards passing the device down, and possibly adding a
numeric version of the device_version/device_clc_version fields to
prevent having to do as much string matching in what was patch 4.
Thoughts?
--Aaron
>
> Jan
>
>>
>> // clc.h requires that this macro be defined:
>> c.getPreprocessorOpts().addMacroDef("cl_clang_storage_class_specifiers");
>
> --
> Jan Vesely <jan.vesely at rutgers.edu>
More information about the mesa-dev
mailing list