[LLVMdev] Opaque types in function parameters

[Kenneth Uildriks]

2009/9/15 Carlos Sánchez de La Lama <carlos.delalama at urjc.es>:
> Hi all,
>
> I am creating a function and trying to call it using the LLVM API. It
> seems that whenever the function type includes an opaque-typed
> parameter, the CallInst::Create call causes an assert:
>
> Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)
> == Params[i]->getType()) && "Calling a function with a bad
> signature!"), function init, file /usr/home/csanchez/shared/prj/tce/
> src/llvm-2.5/lib/VMCore/Instructions.cpp, line 294.
>
> If I change the code so the function type has only non-opaque types,
> everything is correct. Of course, the parameters passed to the
> function are correct (I call with either an opaque parameter or an
> integer parameter, to match function type). According to the assert,
> I would say an opaque type always compares to false (even with
> another opaque), but this does not make much sense I do not see such
> in the source. I am using llvm-2.5
>
> Does anybody find an explanation for this?
>
> Thanks a lot,
>
> Carlos
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Every time you call OpaqueType::get, you get a distinct opaque type...
they compare unequal.  If you call OpaqueType::get once and store the
result, and use that same instance in declaring your function and in
calling it, it'll match and the assert will go away.

In other words, while there is only one i32 type, and using the API to
fetch it any number of times will always fetch the same one, there can
be an unlimited number of different opaque types... it's up to you to
make sure you're using the same opaque type in situations where you
need them to match, and to make sure you're using different opaque
types in situations where you don't want them to match.

Also, when writing stuff using a single opaque type out to IR, those
uses will come back as using different opaque types unless you gave
your opaque type a name in the module's type symbol table.

(Also, you can't have a parameter or a value of type opaque... it must
be of type pointer-to-opaque.  Opaque is not a first-class type.)