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

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Nov 15 08:20:02 PST 2021


            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


#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
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash

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 {
  %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>

More information about the llvm-bugs mailing list