[LLVMdev] Documentation of bitcasts in calls

[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>
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> 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
>> <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
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> 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         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/8615f021/attachment.html>