thr3ads.net - llvm dev - [LLVMdev] [NVPTX] Backend cannot handle array-of-arrays constant [Sep 2012]

If this information is useful, please help other people find it:
Share via:

Dmitry N. Mikushin

2012-Sep-04 13:57 UTC

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

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?

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)

Justin Holewinski

2012-Sep-06 14:21 UTC

head link

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

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

Dmitry N. Mikushin

2012-Nov-10 00:20 UTC

head link

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

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
>

Maybe Matching Threads

Search for more reasonably related threads

llvm dev - Sep 2012 - [LLVMdev] [NVPTX] Backend cannot handle array-of-arrays constant

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

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

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

Maybe Matching Threads