[LLVMdev] [NVPTX] Backend cannot handle array-of-arrays constant

Justin Holewinski justin.holewinski at gmail.com
Thu Sep 6 07:21:50 PDT 2012


On 09/04/2012 09:57 AM, Dmitry N. Mikushin wrote:
> I think our test case demonstrates that requiring the array item being
> initialized to be constant is incorrect. NVPTX does not crash anymore
> and produces correct result with the following change:
>
> --- NVPTXAsmPrinter.cpp	2012-09-03 15:14:00.000000000 +0200
> +++ NVPTXAsmPrinter.cpp	2012-09-04 15:47:17.859398193 +0200
> @@ -1890,17 +1890,15 @@
>     case Type::ArrayTyID:
>     case Type::VectorTyID:
>     case Type::StructTyID: {
> -    if (isa<ConstantArray>(CPV) || isa<ConstantVector>(CPV) ||
> -        isa<ConstantStruct>(CPV)) {
> +    if (isa<ConstantAggregateZero>(CPV))
> +      aggBuffer->addZeros(Bytes);
> +    else
> +    {
>         int ElementSize = TD->getTypeAllocSize(CPV->getType());
>         bufferAggregateConstant(CPV, aggBuffer);
>         if ( Bytes > ElementSize )
>           aggBuffer->addZeros(Bytes-ElementSize);
>       }
> -    else if (isa<ConstantAggregateZero>(CPV))
> -      aggBuffer->addZeros(Bytes);
> -    else
> -      llvm_unreachable("Unexpected Constant type");
>       break;
>     }
>
> It it OK, how do you think?

What is the type of CPV that you are seeing?

>
> Thanks,
> - D.
>
> 2012/9/4 Dmitry N. Mikushin <maemarcus at gmail.com>:
>> NVCC successfully handles the same IR, if we try to process the same
>> .cu file with clang+nvptx and nvcc:
>>
>> CLANG/NVPTX:
>> =============
>>
>> $ cat dayofweek.cu
>> __attribute__((device)) char yweek[7][4] = { "MON", "TUE", "WED",
>> "THU", "FRI", "SAT", "SUN" };
>> $ clang -cc1 -emit-llvm -fcuda-is-device dayofweek.cu -o dayofweek.ll
>> $ cat dayofweek.ll
>> ; ModuleID = 'dayofweek.cu'
>> target datalayout =
>> "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
>> target triple = "x86_64-unknown-linux-gnu"
>>
>> @yweek = global [7 x [4 x i8]] [[4 x i8] c"MON\00", [4 x i8]
>> c"TUE\00", [4 x i8] c"WED\00", [4 x i8] c"THU\00", [4 x i8] c"FRI\00",
>> [4 x i8] c"SAT\00", [4 x i8] c"SUN\00"], align 16
>> $ llc -march="nvptx" dayofweek.ll -o -
>> //
>> // Generated by LLVM NVPTX Back-End
>> //
>>
>> .version 3.0
>> .target sm_10, texmode_independent
>> .address_size 32
>>
>> Unexpected Constant type
>> UNREACHABLE executed at
>> /home/marcusmae/rpmbuild/BUILD/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:1903!
>>
>> NVCC
>> =====
>>
>> $ nvcc -c -keep dayofweek.cu
>> $ cat dayofweek.ptx
>>
>>          .global .align 1 .b8 yweek[28] =
>> {0x4d,0x4f,0x4e,0x0,0x54,0x55,0x45,0x0,0x57,0x45,0x44,0x0,0x54,0x48,0x55,0x0,0x46,0x52,0x49,0x0,0x53,0x41,0x54,0x0,0x53,0x55,0x4e,0x0};
>>
>> 2012/9/3 Dmitry N. Mikushin <maemarcus at gmail.com>:
>>> Dear all,
>>>
>>> Looks like the NVPTX backend cannot handle array-of-arrays contant
>>> (please see the reporocase below). Is it supposed to work? Any ideas
>>> how to get it working? Important for our target applications.
>>>
>>> Thanks,
>>> - Dima.
>>>
>>> $ cat test.ll
>>> ; ModuleID = '__kernelgen_main_module'
>>> target datalayout =
>>> "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v16:16:16-v32:32:32-v64:64:64-v128:128:128-n16:32:64"
>>> target triple = "nvptx64-unknown-unknown"
>>>
>>> @yweek.1533 = internal global [7 x [3 x i8]] [[3 x i8] c"MON", [3 x
>>> i8] c"TUE", [3 x i8] c"WED", [3 x i8] c"THU", [3 x i8] c"FRI", [3 x
>>> i8] c"SAT", [3 x i8] c"SUN"], align 4096
>>>
>>> $ llc -march="nvptx" test.ll -o -
>>> //
>>> // Generated by LLVM NVPTX Back-End
>>> //
>>>
>>> .version 3.0
>>> .target sm_10, texmode_independent
>>> .address_size 32
>>>
>>> Unexpected Constant type
>>> UNREACHABLE executed at
>>> /home/marcusmae/rpmbuild/BUILD/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:1903!
>>> 0  libLLVM-3.2svn.so 0x00007f1bcb71bf0e
>>> 1  libLLVM-3.2svn.so 0x00007f1bcb71bd0a
>>> 2  libpthread.so.0   0x00007f1bca33ccb0
>>> 3  libc.so.6         0x00007f1bc9aa8445 gsignal + 53
>>> 4  libc.so.6         0x00007f1bc9aabbab abort + 379
>>> 5  libLLVM-3.2svn.so 0x00007f1bcb7044a3
>>> 6  libLLVM-3.2svn.so 0x00007f1bcb3e6396
>>> 7  libLLVM-3.2svn.so 0x00007f1bcb3e6494
>>> 8  libLLVM-3.2svn.so 0x00007f1bcb3e39fe
>>> 9  libLLVM-3.2svn.so 0x00007f1bcb3e23e8
>>> 10 libLLVM-3.2svn.so 0x00007f1bcb1a90a1
>>> llvm::FPPassManager::doInitialization(llvm::Module&) + 73
>>> 11 libLLVM-3.2svn.so 0x00007f1bcb1a8fb0
>>> llvm::FPPassManager::runOnModule(llvm::Module&) + 36
>>> 12 libLLVM-3.2svn.so 0x00007f1bcb1a9337
>>> llvm::MPPassManager::runOnModule(llvm::Module&) + 453
>>> 13 libLLVM-3.2svn.so 0x00007f1bcb1a9869
>>> llvm::PassManagerImpl::run(llvm::Module&) + 125
>>> 14 libLLVM-3.2svn.so 0x00007f1bcb1a9a1d
>>> llvm::PassManager::run(llvm::Module&) + 39
>>> 15 llc               0x000000000040ed8e main + 3091
>>> 16 libc.so.6         0x00007f1bc9a9376d __libc_start_main + 237
>>> 17 llc               0x000000000040dac9
>>> Stack dump:
>>> 0.      Program arguments: llc -march=nvptx test.ll -o -
>>> 1.      Running pass 'Function Pass Manager' on module 'test.ll'.
>>> Aborted (core dumped)
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Thanks,

Justin Holewinski




More information about the llvm-dev mailing list