llvm dev - Nov 2015 - Problems using constant memory with NVPTX (cannot cast between two non-generic address spaces)

Hello,

I'm trying to generate some LLVM IR that uses the constant memory address
space. A very simple program aborts from LLVM with the following: LLVM
ERROR: Cannot cast between two non-generic address spaces.

Here's the program I'm trying to build:

; Function Attrs: nounwind
define void @kernel_blur1_s1_x___block_id_x(i32 %blur1.min.0, i32
%"blur1.s1.tent.x$r", i8 addrspace(1)* noalias nocapture %blur1.host,
i8
addrspace(1)* noalias nocapture readonly %input.host, i8 addrspace(4)*
noalias nocapture readonly %tent.host) #1 {
entry:
  %blur1.s1.x.__block_id_x = tail call i32
@llvm.nvvm.read.ptx.sreg.ctaid.x() #0
  %.__thread_id_x = tail call i32 @llvm.nvvm.read.ptx.sreg.tid.x() #0
  %0 = shl i32 %blur1.s1.x.__block_id_x, 4
  %1 = add nsw i32 %0, %blur1.min.0
  %2 = add nsw i32 %1, %.__thread_id_x
  %3 = sub i32 %"blur1.s1.tent.x$r", %blur1.min.0
  %4 = add i32 %3, %2
  %5 = bitcast i8 addrspace(1)* %input.host to i16 addrspace(1)*
  %6 = sext i32 %4 to i64
  %7 = getelementptr inbounds i16, i16 addrspace(1)* %5, i64 %6
  %8 = load i16, i16 addrspace(1)* %7, align 2, !tbaa !8
  %9 = bitcast i8 addrspace(4)* %tent.host to i16 addrspace(4)*
  %10 = sext i32 %"blur1.s1.tent.x$r" to i64
  %11 = getelementptr inbounds i16, i16 addrspace(4)* %9, i64 %10
  %12 = load i16, i16 addrspace(4)* %11, align 2, !tbaa !9
  %13 = mul i16 %12, %8
  %14 = sub nsw i32 %2, %blur1.min.0
  %15 = bitcast i8 addrspace(1)* %blur1.host to i16 addrspace(1)*
  %16 = sext i32 %14 to i64
  %17 = getelementptr inbounds i16, i16 addrspace(1)* %15, i64 %16
  %18 = load i16, i16 addrspace(1)* %17, align 2, !tbaa !6
  %19 = add i16 %18, %13
  store i16 %19, i16 addrspace(1)* %17, align 2, !tbaa !6
  ret void
}

The program looks correct to me w.r.t. address spaces. The error seems to
come from NVPTXDAGToDAGISel::SelectAddrSpaceCast, but I don't believe the
program needs or uses any address space casts?

Please let me know if I'm missing any information you need to help diagnose
the problem!

Thanks,
Dillon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151104/bd7b97b4/attachment.html>