[LLVMdev] Documentation of bitcasts in calls

[Thomas Ströder]

Dear James and Jeremy,

Thanks for the quick help!
While I found the documentation for the textual IR, I didn't find any
for the bitcode. Could you point me to some documentation about its
syntax and semantics?

Best regards,

  Thomas


Am 13.07.2015 um 15:00 schrieb James Molloy:
> Hi Thomas,
> 
> That syntax is expressing a ConstantExpr of type BitCast.
> 
> I echo Jeremy's comment that the textual IR isn't meant to be parsed by
> non-LLVM tools - you'd have much better stability using bitcode instead,
> which has a backwards-compatibility guarantee.
> 
> Cheers,
> 
> James
> 
> On Mon, 13 Jul 2015 at 13:35 Jeremy Lakeman <Jeremy.Lakeman at gmail.com
> <mailto:Jeremy.Lakeman at gmail.com>> wrote:
> 
>     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
>     <mailto: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
>         <mailto:stroeder at informatik.rwth-aachen.de>
>         LuFG Informatik 2     http://verify.rwth-aachen.de/stroeder
>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__verify.rwth-2Daachen.de_stroeder&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=6drm1kA9bTnON-PUHJYeus9Hrihu1CUkeWU81YdAJRU&s=D6tPQqOTGpv0s0KRdAiiNWkQ8M5n7NWhgEnD0xxxD84&e=>
>         RWTH Aachen           phone: +49 241 80-21241
>         <tel:%2B49%20241%2080-21241>
> 
> 
>         _______________________________________________
>         LLVM Developers mailing list
>         LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>       
>          http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>       
>      http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150713/cf09eaee/attachment.sig>