- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm trying to apply explicit banking on one of my kernel's local memories, but unfortunately I'll receive a weird LLVM error. Here is the local memory definition, with the banking applied:
__local lane_data __attribute__((numbanks(2),bankwidth(64))) win_buffer[2][16]
The lane_data data structure is specified as:
typedef struct {
DPTYPE data[VEC_SIZE];
} lane_data;
DPTYPE is char and VEC_SIZE is 4. This is the error I get:
aocl-opt: /build/swbuild/SJ/nightly/18.1/222/l64/p4/acl/llvm/lib/IR/Instructions.cpp:2565: static llvm::CastInst* llvm::CastInst::Create(llvm::Instruction::CastOps, llvm::Value*, llvm::Type*, const llvm::Twine&, llvm::Instruction*): Assertion `castIsValid(op, S, Ty) && "Invalid cast!"' failed.
/home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x2a)[0x7f3c6224671a]
/home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(_ZN4llvm3sys17RunSignalHandlersEv+0x3e)[0x7f3c6224445e]
/home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(+0xb0b804)[0x7f3c62244804]
/lib64/libpthread.so.0(+0x39d680f7e0)[0x7f3c6152b7e0]
/lib64/libc.so.6(gsignal+0x35)[0x7f3c6099e4f5]
/lib64/libc.so.6(abort+0x175)[0x7f3c6099fcd5]
/lib64/libc.so.6(+0x39d642b66e)[0x7f3c6099766e]
/lib64/libc.so.6(__assert_perror_fail+0x0)[0x7f3c60997730]
/home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(_ZN4llvm8CastInst6CreateENS_11Instruction7CastOpsEPNS_5ValueEPNS_4TypeERKNS_5TwineEPS1_+0x27f)[0x7f3c6233a38f]
/home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(+0x1d6791c)[0x7f3c634a091c]
/home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(+0x1d6bfe1)[0x7f3c634a4fe1]
/home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x2d8)[0x7f3c6235a6b8]
/home/tools/altera/18.1-pro/hld/linux64/bin/../../llvm/bin/aocl-opt(main+0x236b)[0x556abe6e721b]
/lib64/libc.so.6(__libc_start_main+0x100)[0x7f3c6098ad20]
/home/tools/altera/18.1-pro/hld/linux64/bin/../../llvm/bin/aocl-opt(+0x27fad)[0x556abe6e7fad]
Stack dump:
0. Program arguments: /home/tools/altera/18.1-pro/hld/linux64/bin/../../llvm/bin/aocl-opt -march=fpga -O3 -board /home/tools/altera/18.1-pro/hld/board/nalla_pcie/hardware/p385a_sch_ax115/board_spec.xml -libfile /home/user/sbiookag/PipeCNN/project/device/RTL/rtl_lib.aoclib -dbg-info-enabled --soft-elementary-math=false -pass-remarks-output=pass-remarks.yaml conv_pipe_test.fpga.bc -o conv_pipe_test.kwgid.bc
1. Running pass 'Fixup for user specified Memory Attributes' on module 'conv_pipe_test.fpga.bc'.
Error: Optimizer FAILED.
Refer to conv_pipe_test/conv_pipe_test.log for details.
Anyone has a clue what is going on here? Could it be my local memory data type?
- Tags:
- OpenCL™
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is a compiler crash due to some bug in the compiler; such issues cannot be directly addressed by the programmer. I recommend using the latest version of Quartus (v19.1) if you have a compatible BSP to see if the issue still occurs. If it does, the issue should be passed on to Intel engineers (I guess the forum moderators can do that). Since the fix will likely take a while to be implemented, your only choice in the meantime is likely to modify your code line by line to see which line triggers the crash and then try to come up with an alternative implementation that produces the same kernel behavior without including that line so that the compiler crash is avoided.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is a compiler crash due to some bug in the compiler; such issues cannot be directly addressed by the programmer. I recommend using the latest version of Quartus (v19.1) if you have a compatible BSP to see if the issue still occurs. If it does, the issue should be passed on to Intel engineers (I guess the forum moderators can do that). Since the fix will likely take a while to be implemented, your only choice in the meantime is likely to modify your code line by line to see which line triggers the crash and then try to come up with an alternative implementation that produces the same kernel behavior without including that line so that the compiler crash is avoided.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks much for the help. I'll definitely try the new version.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page