[llvm-bugs] [Bug 52511] New: [amdgpu] const globals incorrectly marked addrspace(4)

[via llvm-bugs]

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

            Bug ID: 52511
           Summary: [amdgpu] const globals incorrectly marked addrspace(4)
           Product: OpenMP
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Clang Compiler Support
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jonathanchesterfield at gmail.com
                CC: llvm-bugs at lists.llvm.org

Given

#include <complex>
#include <cmath>
#include <omp.h>

#pragma omp declare target

static const double smallx = 1.0e-5;

static const double log_smallx = log(smallx);

#pragma omp end declare target


clang++ -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa   math_exp.cpp -o
math_exp  -lm -save-temps

unhandled address space
UNREACHABLE executed at
/home/amd/llvm-project/llvm/lib/Target/AMDGPU/SIISelLowering.cpp:8869!
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.

IR emitted from clang with -disable-llvm-passes contains a global constructor
to do the log call,

define internal void @__omp_offloading__10303_4068b_log_smallx_l9_ctor() #4 {
entry:
  %call = call double @"_ZL28log$ompvariant$S2$s7$Pamdgcnd"(double
1.000000e-05) #17
  store double %call, double addrspace(4)* @_ZL10log_smallx, align 8, !tbaa !9
  ret void
}

The backend (probably rightly) chokes on that, addrspace(4) is constant in the
sense that the value has to be set before kernel execution begins. 

The optimal codegen, I think, would look like a global ctor that writes to that
value as an addrspace(1) value, then the other kernels load it as an
addrspace(4) value. Thus we can use scalar loads on it, after the global ctor
ran to initialise it.

A less clever way to fix this ICE is to find the point in clang that tags the
const variable as addrspace(4) and back it off to only do so when the
initialiser is already available as a constant.

I think this is an artefact of how constexpr is handled by target regions - I
suspect log is marked constexpr in a glibc header, but it isn't actually
constexpr in the hip math headers - but have not confirmed that theory.

-- 
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/20211115/a8cf39b2/attachment.html>