(original) (raw)
Textual LLVM IR is not guaranteed to be stable between versions. Even LLVM's parser is not guaranteed to be backwards compatible.
There was/is a move afoot to remove types from pointers, so explicit bitcasts are no longer required or used. Instead each instruction that uses a pointer will also take a type parameter for that pointer.On Mon, Jul 13, 2015 at 9:16 PM, Thomas Ströder <stroeder@informatik.rwth-aachen.de> wrote:
Dear all,
I just stumbled over the following instruction in the LLVM IR of a C
program compiled with clang:
%26 = call i32 (...)\* bitcast (i32 (i32, i32, i32, i32, i32)\*
@KeWaitForSingleObject to i32 (...)\*)(i32 %23, i32 %24, i32 %25, i32 0,
i32 0)
Since our LLVM Parser choked on this instruction, I tried to check the
documentation, but did not find anything about such nested bitcasts
within calls. What is the exact syntax and semantics (while I can guess
the latter, especially the former is interesting for me when building a
parser for LLVM IR) for such instructions and/or where is this
documented? In particular, the parantheses around the arguments of the
bitcast are confusing me.
Alternatively, is there a way to tell clang not to inline such bitcasts,
but have them in a separate instruction before and use the result in the
call?
Best regards,
Thomas
\--
Thomas Ströder mailto:stroeder@informatik.rwth-aachen.de
LuFG Informatik 2 http://verify.rwth-aachen.de/stroeder
RWTH Aachen phone: +49 241 80-21241
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev