OpenCL Compiler Local Memory Address Space Splitter fails

[eheim]

Hello,

when compiling my OpenCL kernels with AOCL 17.1, I get the following error:

aoc: Optimizing and doing static analysis of code...aocl-opt: Value.cpp:287: void llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed.0 libLLVM-3.0.so 0x00007fad087cb98f1 libLLVM-3.0.so 0x00007fad087cd9022 libpthread.so.0 0x00007fad079f43c03 libc.so.6 0x00007fad0718ad7f gsignal + 2714 libc.so.6 0x00007fad07175672 abort + 2935 libc.so.6 0x00007fad071755486 libc.so.6 0x00007fad071833967 libLLVM-3.0.so 0x00007fad08f9a93b llvm::Value::replaceAllUsesWith(llvm::Value*) + 3958 libLLVM-3.0.so 0x00007fad08c82240 acl::LocalMemSplit::UpdateLoadStoreTypes(llvm::Module&) + 1769 libLLVM-3.0.so 0x00007fad08c8e03f acl::LocalMemSplit::runOnModule(llvm::Module&) + 33510 libLLVM-3.0.so 0x00007fad08f88df1 llvm::MPPassManager::runOnModule(llvm::Module&) + 57711 libLLVM-3.0.so 0x00007fad08f88f9b llvm::PassManagerImpl::run(llvm::Module&) + 18712 aocl-opt 0x00000000004194dd main + 476513 libc.so.6 0x00007fad07177223 __libc_start_main + 24314 aocl-opt 0x000000000040ccc9Stack dump:0. Program arguments: /home/ksiks/intelFPGA/17.1/hld/linux64/bin/aocl-opt --acle ljg7wk8o1[...]z0f -board /home/user/intelFPGA/17.1/hld/board/de1_soc/hardware/de1_soc_sharedonly/board_spec.xml -profile all -fp-relaxed=true -dbg-info-enabled --grif --soft-elementary-math=false --fas=false --wiicm-disable=true device.1.bc -o device.kwgid.bc 1. Running pass 'Local Memory Address Space Splitter.' on module 'device.1.bc'.Error: Optimizer FAILED.

I can't find any documentation about or reasons for this error in the web. Does anyone know what exactly this error means? Why and how is the local memory (I'm guessing __local?) being split and how can this fail?

EDIT: I created a minimal (non-)working example: https://pastebin.com/3j6my0YA. Can anyone confirm that this crashes the compiler in 16.1 and 17.1 (possibly other versions, too)? Does anyone have an idea what could be the problem in this code? Keep in mind that this is an artificial example and does not really need the buffers etc. that are being created, nor do the operations make much sense...

[HRZ]

This is an internal crash in the OpenCL compiler. Nobody knows (or could possibly know) why it happens other than Intel's engineers who created the compiler. My recommendation is to try other (preferably newer) versions of the compiler to see if the issue has been fixed. If not, you have no choice but to change your design strategy. Such crashes are more frequent in designs which are not very FPGA-friendly.

[eheim]

Thanks for your reply! Unfortunately I cannot use the 18.0 SDK as there is no 18.0 BSP for the Terasic DE1-SoC available yet. Maybe I could try an older version and see if it has the same issue or not. However, I would have to re-write large parts of the design that make use of features introduced in recent versions of the SDK.

Is there any chance Intel employees are going to see this message and provide a brief explanation what could be causing the crash? At least the call stack and error message could give them a hint and allow them to help me narrow down the possible reasons.

[eheim]

I created a minimal (non-)working example: https://pastebin.com/3j6my0YA. Can anyone confirm that this crashes the compiler in 16.1 and 17.1 (possibly other versions, too)? Does anyone have an idea what could be the problem in this code? Keep in mind that this is an artificial example and does not really need the buffers etc. that are being created, nor do the operations make much sense...

[HRZ]

Your code crashes the compiler from v16.0 all the way to v18.1. I would have recommended you to open a support ticket with Altera directly but since everything has been moved to Intel's platform, it seems they don't do support tickets anymore except for large high-paying customers. :D

[Audrey_K_Intel]

Intel engineer here. The problem you have encountered is an assertion in the compiler code, which as you suspected (usually) indicates a bug in the tool, not a problem with the input. I can't see anything obviously wrong with your OpenCL code that would trigger this.

I've opened a ticket in the engineering system to have this looked at, with a cross-link to this post.

Thanks for taking the time to post this issue! This is valuable feedback; the fact that it crashes in multiple releases suggests a corner case we failed to consider. It's extremely helpful to have a minimal non-working example to debug from.

[eheim · Accepted solution]

Thank you for your reply, AKert. It is great to hear that my report is of some value. Meanwhile, I have found that the issue seems to be caused by reading from global memory and writing to an Intel FPGA channel in a single statement. When replacing

UTL_WRITE_CH(ch_1, data1[j]); UTL_WRITE_CH(ch_2, buf_d2[i]);

with (make sure to use the actual types)

const my_type1 temp1 data1[j] UTL_WRITE_CH(ch_1, temp1);   const my_type2 temp2 buf_d2[i] UTL_WRITE_CH(ch_2, temp2);

the error goes away. It may or may not be related to also using char (8 bits) buffers.