What does LLVM ERROR: Cannot select.. mean?


I am currently working on Shark, a backend for the Hotspot VM of
OpenJDK, which uses LLVM to generate target machine code.

I am currently running into an LLVM error message, and I don't know
exactly what it means or what I am doing wrong:

LLVM ERROR: Cannot select: 0x7ffff01295d0: f32,ch = AtomicLoad
0x7fffcc071b10:1, 0x7fffcc041e70<Volatile LD4[%addr29](align=8)>
[ORD=48] [ID=18]
  0x7fffcc041e70: i64 = add 0x7fffcc071b10, 0x7ffff012a2e0 [ORD=46]
    0x7fffcc071b10: i64,ch = load 0x7ffff0129de0:1, 0x7fffcc042270,
0x7ffff01298d0<LD8[%109]> [ORD=45] [ID=15]
      0x7fffcc042270: i64 = add 0x7fffcc041d70, 0x7ffff012a0e0 [ORD=43]
        0x7fffcc041d70: i64,ch = CopyFromReg 0x7ffff00f26f0,
0x7ffff012a1e0 [ORD=37] [ID=9]
          0x7ffff012a1e0: i64 = Register %vreg41 [ORD=37] [ID=1]
        0x7ffff012a0e0: i64 = Constant<48> [ORD=43] [ID=6]
      0x7ffff01298d0: i64 = undef [ORD=39] [ID=3]
    0x7ffff012a2e0: i64 = Constant<204> [ORD=46] [ID=7]
In function: Test6796786::main

I suspect it is related to the implementation of Shark's volatile field
access, as it's the only place where I use AtomicLoad, but as I said, I
don't know how to parse this error message. I am pretty sure that
volatile field access works otherwise, Shark can run a great number of
fairly complex application and testsuites, in particular the
java-concurrency-torture which exercises atomics fairly hard. Any help
would be greatly appreciated.

I am working with latest LLVM from the 3.2 branch, on an amd64 machine
(my laptop) and turned off all optimizations. The full LLVM code of the
function in question can be found here:


(ignore the first few lines, they are the other methods that are
compiled by this testcase.)


The instruction selection cannot find a way to convert this into machine instructions. Most likely there is no pattern to match this part of the graph in your .td file.

You can see what's going on during selection with -mllvm -debug-only=isel. The dumps are somewhat cumbersome to read, but not hard overall.


Thanks for the information. I found out that this is because of this
little restriction for atomic load/store:

"The type of the pointee must be an integer type whose bit width is a
power of two greater than or equal to eight and less than or equal to a
target-specific size limit"

I did atomic store/loads without conversion and this lead to the LLVM
ERROR that I originally posted. Issuing a bitcast after the load and
before the store resolved it.

Another little (potential) issue relating to the above restriction: how
can I find out (programmatically) what is the "target-specific size
limit" ? In particular, I am worried about some platforms not supporting
64bit atomics. Any ideas? I'd like to avoid tons of #ifdef PLATFORM
specific code if possible.

Best regards,

I believe this refers to the maximum native integer size for a given machine. That is specified in the data layout string, and can be programatically obtained by querying analysis "DataLayout".
E.g. something like

DataLayout *DL = getAnalysis<DataLayout>();
if (!DL->isLegalInteger(64/*bits*/))