search for: nvptxasmprint

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<Co...

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<ConstantVect...

...ot;, [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 0...

...[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.co...

...TargetLowering()`. However, because MF is nullptr when lowering initializers of global variables, it won't work. My impression is that this is not possible because every function has its own TargetLowering instance. Is that correct? NVPTX solves the problem by having a method on it's NVPTXAsmPrinter class, which is mostly a copy of AsmPrinter::lowerConstant() and knows how to handle addrspacecasts. However, this probably isn't a solution for e.g. X86. Suggestions are highly welcome. -Manuel

On Fri, Dec 19, 2014 at 12:56 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > However, I think this would set a bad precedent. There's nowhere else > (that I know of) where we accept two versions of assembly. The > LLParser is relatively easy to work with because it doesn't have that > kind of historical baggage. I can think of two precedents:

...39;: /home/bollu/.local/include/llvm/Config/Targets.def:27: undefined reference to `LLVMInitializeNVPTXTarget' CMakeFiles/sxhc.dir/src/main.cpp.o: In function `llvm::InitializeAllAsmPrinters()': /home/bollu/.local/include/llvm/Config/AsmPrinters.def:28: undefined reference to `LLVMInitializeNVPTXAsmPrinter' collect2: error: ld returned 1 exit status CMakeFiles/sxhc.dir/build.make:285: recipe for target 'sxhc' failed make[2]: *** [sxhc] Error 1 CMakeFiles/Makefile2:131: recipe for target 'CMakeFiles/sxhc.dir/all' failed make[1]: *** [CMakeFiles/sxhc.dir/all] Error 2 Makefile:83:...

...in + 237 14 libc.so.6 0x00007f986687576d __libc_start_main + 237 15 llc 0x00000000008bf229 ===== What my modulePass does is to print all of the function name in the module. I use setPreservesAll() in getAnalysisUsage(), so there isn't any pass dependency cycle. I notice that NVPTXAsmPrinter says it does static initialization. I'm not sure if it is related to this error. Is there any advice to solve this error? And I also want to know if there is a way to verify if there is a pass dependency cycle. Thanks for any advice. Antony Yu -------------- next part -------------- An HTM...

....ll -o nbody_kernel.ll llc nbody_kernel.ll -o nbody_kernel.ptx After execution of the last command(llc) I get a UNREACHABLE executed! error with the following stack trace [DEVICE-C++] nbody.kernel.cpp unexpected address space UNREACHABLE executed at /home/pratnali/LLVM/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:1317! 0 libLLVM-3.3svn.so 0x00007f3857bdf0cb llvm::sys::PrintStackTrace(_IO_FILE*) + 43 1 libLLVM-3.3svn.so 0x00007f3857bde74a 2 libpthread.so.0 0x00007f3856c3c460 3 libc.so.6 0x00007f3855a90b15 gsignal + 53 4 libc.so.6 0x00007f3855a91f96 abort + 390 5 libLLVM-3....

...76d __libc_start_main + 237 > 15 llc 0x00000000008bf229 > ===== > > What my modulePass does is to print all of the function name in the > module. > I use setPreservesAll() in getAnalysisUsage(), so there isn't any pass > dependency cycle. > > I notice that NVPTXAsmPrinter says it does static initialization. I'm not > sure if it is related to this error. > > Is there any advice to solve this error? And I also want to know if there > is a way to verify if there is a pass dependency cycle. > > > Thanks for any advice. > Antony Yu > >...

...el.ll -o nbody_kernel.ptx > > After execution of the last command(llc) I get a UNREACHABLE executed! > error > with the following stack trace > > [DEVICE-C++] nbody.kernel.cpp > unexpected address space > UNREACHABLE executed at > /home/pratnali/LLVM/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:1317! > 0 libLLVM-3.3svn.so 0x00007f3857bdf0cb > llvm::sys::PrintStackTrace(_IO_FILE*) + 43 > 1 libLLVM-3.3svn.so 0x00007f3857bde74a > 2 libpthread.so.0 0x00007f3856c3c460 > 3 libc.so.6 0x00007f3855a90b15 gsignal + 53 > 4 libc.so.6 0x00007f3855a91f96 a...

On Apr 8, 2013, at 2:55 PM, "Robinson, Paul" <Paul_Robinson at playstation.sony.com> wrote: I keep seeing "this is a layering violation" comments on the lists. > While there are a few llvm.org pages that mention layers in passing, > there is nothing (that I've found) actually specifying the layers. > Trying to infer the layering from the code is tedious and

I keep seeing "this is a layering violation" comments on the lists. While there are a few llvm.org pages that mention layers in passing, there is nothing (that I've found) actually specifying the layers. Trying to infer the layering from the code is tedious and error-prone (or we wouldn't see so many violations in code reviews, eh?). Now, I understand that Google has some sort

..., I can try to clean up the Verify functions first. > > Yes, we probably shouldn't be using Verify much. I haven't looked at > all the use cases though. Verify called from the following 12 files other than DebugInfo DIBuilder Dwarf Index: tools/opt/opt.cpp Index: lib/Target/NVPTX/NVPTXAsmPrinter.cpp Index: lib/Transforms/Utils/Local.cpp Index: lib/Transforms/Instrumentation/GCOVProfiling.cpp Index: lib/Transforms/IPO/StripSymbols.cpp Index: lib/Transforms/IPO/DeadArgumentElimination.cpp Index: lib/CodeGen/SelectionDAG/FastISel.cpp Index: lib/CodeGen/SelectionDAG/SelectionDAGDumper.cpp In...

...gt; Yes, we probably shouldn't be using Verify much. I haven't looked at >> all the use cases though. >> >> >> Verify called from the following 12 files other than DebugInfo DIBuilder >> Dwarf >> Index: tools/opt/opt.cpp >> Index: lib/Target/NVPTX/NVPTXAsmPrinter.cpp >> Index: lib/Transforms/Utils/Local.cpp >> Index: lib/Transforms/Instrumentation/GCOVProfiling.cpp >> Index: lib/Transforms/IPO/StripSymbols.cpp >> Index: lib/Transforms/IPO/DeadArgumentElimination.cpp >> Index: lib/CodeGen/SelectionDAG/FastISel.cpp >> Ind...

...se::getParamByValType 4 llvm::OpenMPIRBuilder::getOrCreateIdent 3 getFoldedSizeOf 3 llvm::NVPTXAsmPrinter::emitFunctionParamList 3 llvm::GlobalAlias::create 3 llvm::IRBuilder 3 llvm::SCEVExp...

On Fri, Jun 21, 2013 at 12:33 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 21, 2013, at 11:56 AM, Eric Christopher wrote: > >> On Fri, Jun 21, 2013 at 11:50 AM, Manman Ren <mren at apple.com> wrote: >>> >>> On Jun 21, 2013, at 11:35 AM, Eric Christopher wrote: >>> >>>> On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at