<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>> call void @llvm.dbg.declare( { }* bitcast(i32* %loc0 to { }*), { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable1 to { }*) )
<br>
<br>This is not legal. The distinction here is that the bitcast as an argument is
<br>a constant expression and requires constant arguments, and %loc0 is not constant.
<br>Introducing the temp variable is the "right way" to do this.<br>
<br> - Daniel
<br>
<br>----- Original Message ----
<br>From: Dave Cope <dwcope@gmail.com>
<br>To: llvmdev@cs.uiuc.edu
<br>Sent: Friday, April 4, 2008 10:11:30 AM
<br>Subject: [LLVMdev] Problem using 'bitcast'
<br>
<br> I have been trying to compile some Llvm code that I generate, and I am running into a problem assembling my ll code. Here is a snippet of the code I am trying to compile:
<br> %loc0 = alloca i32
<br> call void @llvm.dbg.declare( { }* bitcast(i32* %loc0 to { }*), { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable1 to { }*) )
<br>
<br>I get an error from the second line of code:
<br> Invalid reference to global
<br>
<br>Just to try to get the code to compile, I replaced the reference to %loc0 with null:
<br> %loc0 = alloca i32
<br> call void @llvm.dbg.declare( { }* bitcast(i32* null to { }*), { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable1 to { }*) )
<br>
<br>This code compiles fine, but obviously will not give the end result I want.
<br>
<br>My current solution is to introduce a temporary variable like this:
<br> %loc0 = alloca i32
<br> %loc0_void = bitcast i32* %loc0 to { }*
<br> call void @llvm.dbg.declare( { }* %loc0_void, { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable1 to { }*) )
<br>
<br>I would prefer to make the first code snippet work (to avoid adding temporary variables and cluttering up the ll code). But my workaround is alright for now.
<br>
<br>I am wondering why my first code snippet doesn't compile properly. Am I doing something incorrect? Or is this possibly and LLVM bug of some kind?
<br>
<br>Thanks a lot,
<br>Dave Cope
<br>
<br>
<br>
<br>
<br></div></div></body></html>