[LLVMdev] What does LLVM ERROR: Cannot select.. mean?

[Roman Kennke]

Hello,

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]
[ID=17]
0x7fffcc071b10: i64,ch = load 0x7ffff0129de0:1, 0x7fffcc042270,
0x7ffff01298d0<LD8[%109]> [ORD=45] [ID=15]
0x7fffcc042270: i64 = add 0x7fffcc041d70, 0x7ffff012a0e0 [ORD=43]
[ID=10]
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:

http://pastebin.com/efT9Eh5Z

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

Regards,
Roman


_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Krzysztof Parzyszek]

On 12/3/2012 5:07 PM, Roman Kennke wrote:
> Hello,
>
> 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:

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.

-Krzysztof


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[Roman Kennke]

Am Montag, den 03.12.2012, 17:40 -0600 schrieb Krzysztof Parzyszek:
> On 12/3/2012 5:07 PM, Roman Kennke wrote:
> > Hello,
> >
> > 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:
>
> 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,
Roman

[Krzysztof Parzyszek]

On 12/4/2012 12:59 PM, Roman Kennke wrote:
>
> 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"

> [...]

> 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.

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*/))
handle_integer_that_is_too_large();

-Krzysztof



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation