[llvm-bugs] [Bug 50162] New: Problem automatically deducing template parameters with address spaces in OpenCL

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50162

            Bug ID: 50162
           Summary: Problem automatically deducing template parameters
                    with address spaces in OpenCL
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: OpenCL
          Assignee: unassignedclangbugs at nondot.org
          Reporter: drohr at jwdt.org
                CC: anastasia.stulova at arm.com, llvm-bugs at lists.llvm.org

Created attachment 24810
  --> https://bugs.llvm.org/attachment.cgi?id=24810&action=edit
testcase

I am not sure whether this is a real bug in the sense of the OpenCL
specification, it resembles a bit what was discussed here:
https://bugs.llvm.org/show_bug.cgi?id=42033

My problem is that C++ for OpenCL fails to deduce the template parameters in
many cases, when address spaces get involved.

Note: the following test case requires https://reviews.llvm.org/D101168.
I have been testing with clang trunk (clang version 13.0.0
(https://github.com/llvm/llvm-project.git
837fded984ed36fa462daeb0f671eec58f71ae26)) + https://reviews.llvm.org/D101168
and with the following command line:
/home/qon/alice/llvm-project/build/bin/clang++ -O0 -cl-std=clc++ -x cl
-emit-llvm --target=spir64-unknown-unknown -Xclang -fdenormal-fp-math-f32=ieee
-cl-mad-enable -cl-no-signed-zeros -ferror-limit=1000
-Dcl_clang_storage_class_specifiers -c fail.cl -o test.bc

The error I am getting is:

In file included from ../Base/opencl-common/GPUReconstructionOCL.cl:80:
In file included from ../Base/GPUReconstructionIncludesDevice.h:104:
../Refit/GPUTrackingRefit.cxx:101:7: error: no viable overloaded '='
  trk = trkX;
  ~~~ ^ ~~~~
../Refit/GPUTrackingRefit.cxx:215:3: note: in instantiation of function
template specialization 'o2::gpu::GPUTrackingRefit::convertTrack<__private
o2::track::TrackParametrizationWithError<>, __generic
o2::gpu::GPUTPCGMMergedTrack, const __generic o2::base::PropagatorImpl<float>
*__private>' requested here
  convertTrack(trk, trkX, prop, &TrackParCovChi2);
  ^
/home/qon/alice/O2/DataFormats/Reconstruction/include/ReconstructionDataFormats/TrackParametrizationWithError.h:50:48:
note: candidate function not viable: no known conversion from 'const __generic
o2::gpu::GPUTPCGMMergedTrack' to 'const __generic
o2::track::TrackParametrizationWithError<>' for 1st argument
                TrackParametrizationWithError& operator=(const
TrackParametrizationWithError& src) = default;
                                               ^
/home/qon/alice/O2/DataFormats/Reconstruction/include/ReconstructionDataFormats/TrackParametrizationWithError.h:51:48:
note: candidate function not viable: no known conversion from 'const __generic
o2::gpu::GPUTPCGMMergedTrack' to '__generic
o2::track::TrackParametrizationWithError<>' for 1st argument
                TrackParametrizationWithError&
operator=(TrackParametrizationWithError&& src) = default;
                                               ^
In file included from ../Base/opencl-common/GPUReconstructionOCL.cl:80:
In file included from ../Base/GPUReconstructionIncludesDevice.h:104:

I think the problem is that it deduces the template parameters as "__generic
TYPE&" etc, and that will not work in all cases, particular if references to
non generic variables are passed in. But then, if I explicitly state the
template parameters, as I do in workaround.patch, it works. What I am doing is
just ommiting the address space completely, so it will now work with all of
them (except __constant).
Another workaround is to define the template function in the way
template <class T> void foo(__generic T& bar) ...
but that has the problem that now it only works with the __generic address
space, so it breaks when one passes in local variables.

Overall, this situation makes templates with references / pointers pretty much
unusable. There are workarounds in our code all over the place, so I am
wondering whether one could improve the situation in general. I think the
problem is that the address space is part of the template type. Not sure what
could be a proper solution, but frankly I do not understand why the address
space must become a part of the template type at all, why cannot this be
stripped?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210429/8d46ee21/attachment-0001.html>