https://bugs.llvm.org/show_bug.cgi?id=40778
Anastasia Stulova <anastasia.stul...@arm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #23 from Anastasia Stulova <anastasia.stul...@arm.com> ---
I believe the issues you are reporting now should be fixed after I commit this:
https://bugs.llvm.org/show_bug.cgi?id=41157
There is another issues with the application that I noticed where atomic
operation is performed on a local address space object by using the overload
with global address space. That doesn't guarantee to work correctly even though
some targets might support this. It does cause compilation for AMDGPU to fail
with another ICE.
This happens specifically in AliGPUTPCProcess_24AliGPUTPCStartHitsFinder0
kernel where a pointer to a member of smem (in a local address space) is passed
into a function CAMath::AtomicAddShared that casts it to global address space
object
::atomic_add( (volatile __global int*) addr, val );
I believe one way to work around this problem is to use templates to
instantiate a function call that uses atomic_add overload with local address
space pointer. But however it might be tricky to write. If you could use
overload with generic address space that libclc doesn't support unfortunately
(because it's doesn't have OpenCL 2.0 functionality), you can avoid the cast
completely.
So perhaps a better idea would be if you switch to a default Clang header that
supports OpenCL 2.0 capability. You would then however need to find OpenCL 2.0
compatible library to execute this code.
As for this bug I agree that it's better to close it now and any other issues
can be tracked by separate bugs. Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
