[LLVMdev] Documentation of bitcasts in calls

Jeremy Lakeman Jeremy.Lakeman at gmail.com
Mon Jul 13 05:15:31 PDT 2015


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.

Casts that don't change the value, don't result in machine instructions
anyway.



On Mon, Jul 13, 2015 at 9:16 PM, Thomas Ströder <
stroeder at 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 at 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 at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150713/21b14d6e/attachment.html>


More information about the llvm-dev mailing list