[LLVMdev] [NVPTX] Backend cannot handle array-of-arrays constant
Dmitry N. Mikushin
maemarcus at gmail.com
Fri Nov 9 16:20:28 PST 2012
Hi Justin,
Bumping another issue with patch suggestion, please see below.
Thanks,
- D.
2012/9/6 Justin Holewinski <justin.holewinski at gmail.com>:
>
> 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