[LLVMdev] Opaque types in function parameters
Carlos Sánchez de La Lama
carlos.delalama at urjc.es
Tue Sep 15 14:42:26 PDT 2009
Ok, this explains my issue :)
Also, I was actually using a pointer-to-opaque at the first place,
obtaining exact same results. I tested with integers and saw it was
ok, and then with plain opaques ang get same error as with pointer-to-
opaques, so when writting to the list I said plain opaques in a try
to simplify the explanation.
El 15/09/2009, a las 20:05, Kenneth Uildriks escribió:
> 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,
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> 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.)
More information about the llvm-dev