[llvm-dev] Help with bitcast instruction

[Alberto Barbaro via llvm-dev]

Hi Tim,
I'm still struggling on the instruction:

call void bitcast (void (%struct.png_struct_def.68*, i8*, i8*
(%struct.png_struct_def.68*, i64)*, void (%struct.png_struct_def.68*,
i8*)*)* @png_set_mem_fn to void (%struct.png_struct_def*, i8*, i8*
(%struct.png_struct_def*, i64)*, void (%struct.png_struct_def*,
i8*)*)*)(%struct.png_struct_def* %create_struct, i8* %mem_ptr, i8*
(%struct.png_struct_def*, i64)* %malloc_fn, void (%struct.png_struct_def*,
i8*)* %free_fn) #15

I'm pretty sure that this is a CallInst but when I try to call
getCalledFunction() I receive a null pointer and that really surprise me.

I would like to understand how to get the function that is called and its
parameters. Can you tell me how please?

Am i right saying that:

(void (%struct.png_struct_def.68*, i8*, i8* (%struct.png_struct_def.68*,
i64)*, void (%struct.png_struct_def.68*, i8*)*)* -> "old parameters type"
(%struct.png_struct_def*, i8*, i8* (%struct.png_struct_def*, i64)*, void
(%struct.png_struct_def*, i8*)*)*) ->  "new parameters type"
(%struct.png_struct_def* %create_struct, i8* %mem_ptr, i8*
(%struct.png_struct_def*, i64)* %malloc_fn, void (%struct.png_struct_def*,
i8*)* %free_fn) "the parameters passed to the png_set_mem_fn"

As a clarification the function is declared like this:

void PNGAPI
png_set_mem_fn(png_structrp png_ptr, png_voidp mem_ptr, png_malloc_ptr
  malloc_fn, png_free_ptr free_fn)


Thanks again


Il giorno dom 10 mar 2019 alle ore 08:59 Tim Northover <
t.p.northover at gmail.com> ha scritto:

> Hi Alberto,
>
> > I would like to understand where bitcast is defined because it is not
> defined within libpng.
>
> It's because the function (@png_set) has been defined to take one kind
> of argument, but is being called with another. In this case the
> difference seems to be whether it takes pointers to
> %struct.png_struct_def or %struct.png_struct_def.68.
>
> This kind of situation isn't terribly common, but can happen for
> example in LTO where two modules are linked together, and one of them
> only has an opaque handle for the type to hide the implementation
> (e.g. from plain "struct png_struct_def;" in C). When that happens
> LLVM can't merge the types, so it adds a numeric tag to one of them,
> and then it has to insert bitcasts in the calls like this so that its
> own type system works.
>
> > I also noticed that the @ is not present, what does the missing @ mean?
> I guess it must be an LLVM function.
>
> The @ is only used directly before a global variable (including a
> declared/defined function). In this case it's buried, but it is there
> (@png_set). In other cases, like when you call a function pointer, it
> will be missing entirely.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190312/e86792d3/attachment.html>