KhronosGroup / KhronosGroup/SPIRV-LLVM-Translator
Translation from OpenCL kernel lang for inline functions
- Dominant language
- LLVM
- Stars
- 625
- Forks
- 279
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 34
Description
Currently we seem to have issues with translation of OpenCL kernel code that has _inline_ functions.
**(OpenCL C)** In C99 frontend doesn't generate definition of inline functions for non-optimized mode because non-optimized mode wouldn't enable inlining. If we generate IR for the following source code in C99:
```
1 inline void foo(int* i) {
2 (*i)++;
3 }
4
5 void bar(){
6 int i;
7 foo(&i);
8 }
```
passing -O0 flag to clang will result in IR:
```
; Function Attrs: noinline nounwind optnone
define void @bar() #0 {
entry:
%i = alloca i32, align 4
call void @foo(i32* %i)
ret void
}
declare void @foo(i32*) #1
```
**(C++ for OpenCL)** Compiling inline functions with C++ based frontends using -O0 flag results in IR where _noinline_ is added. Therefore backends might not be able to inline the functions (the inline hint information is not preserved) and the generated binary won't be as efficient even if optimizations are enabled after SPIR-V injection.
```
; Function Attrs: noinline nounwind optnone
define void @_Z3barv() #0 {
entry:
%i = alloca i32, align 4
call void @_Z3fooPi(i32* %i)
ret void
}
; Function Attrs: noinline nounwind optnone
define linkonce_odr void @_Z3fooPi(i32* %i) #0 comdat {
entry:
%i.addr = alloca i32*, align 8
store i32* %i, i32** %i.addr, align 8
%0 = load i32*, i32** %i.addr, align 8
%1 = load i32, i32* %0, align 4
%inc = add nsw i32 %1, 1
store i32 %inc, i32* %0, align 4
ret void
}
```
Contributor guide
Research direction
Start by examining the OpenCL C and C++ for OpenCL translation paths that consume the shown LLVM IR at -O0. Compare handling of inline function declarations, definitions, and noinline attributes for both examples. Done means inline functions translate correctly in both frontend modes without losing the intended optimization information.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, cpp
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100