AMD IL Code Generator Backend for OpenCL

I am proud to announce that AMD is Open Sourcing AMDIL Code Generator for LLVM 2.9. While this version is not for uptake into LLVM mainline, it does build and is compatible with LLVM 2.9.

This is the first step of the process, so I know there will be issues that show up. In the next few months, we will be providing more unit tests and an LLVM 3.0 compatible version, and finally a TOT version for inclusion into the tree. I look forward to any constructive feedback and will as answer any questions that I can.

For information on the sections of an AMD OpenCL binary, please refer here:

The attached zip file provides the code generator, a patch to LLVM 2.9 that adds the target triple, and a few tests. Again this version is not for submission into the tree, but for people to experiment, examine and provide feedback outside of AMD.

Here are a list of the major known issues:

LLVM-IR that isn’t generated from AMD’s OpenCL frontend does not produce any AMDIL.

Testing is sparse(I’m working on it)

No support for most OpenCL math functions. It is up to the library writers to map from OpenCL function calls to AMDIL intrinsic.

Minor post processing of AMDIL is required for AMDIL source to be accepted by calclCompile/clBuildProgramFromBinary.

The source is the documentation.

Only supports compute shader generation.

The output of the code generator is currently compatible with OpenCL 1.0/1.1 only when processing LLVM-IR from OpenCL binaries generated by AMD APP SDK 2.5 or later with the clBuildProgramSource options “-fbin-llvmir -fno-bin-amdil -fno-bin-exe”.


Micah Villmow

OpenCL GPU Compiler Engineer

AMD Inc. (475 KB)

For future reference, the zip file can also be downloaded from here:

LLVM-IR that isn’t generated from AMD’s OpenCL frontend does not produce any AMDIL.

Is this because of the way metadata is handled? If so, will that technique be documented? Or can it be reasonably inferred from the source code?



We are working on getting the documentation cleaned up to the point where it can be released.

If you look at the test cases, you can infer what needs to be done. Basically since this is targeted

for OpenCL, we annotate OpenCL kernels slightly different than normal functions and that is

what causes the code to be generated. That being said, on my list of things to do is fix this so that

any function will be generated correctly and also create calling conventions that differentiate

between kernels and non-kernels.


Hi Micah, all,

sgv stands for string global variable, and is a string to represent certain attributes in LLVM-IR. This is fairly ancient and in the future we will be using named metadata/metadata nodes. You can look at AMDILModuleInfo.cpp:parseSGV to see what the string can contain, but for most cases, it can be a zero initialized array of i8 of size 1. FGV stores the filename.

LVGV stores information about local arrays that are declared at the kernel scope in OpenCL.

So, basically the structure looks like this:

struct {

const char* kernel;

const char* sgv;

const char* fgv;

const char* lvgv;

unsigned kernel#;

} llvm_global_annotations a.

If you encode your function name with _OpenCL_kernel, it should trigger code generation.

Also, we do not use clang for our frontend, so I’m not sure how it would generate code.