[LLVMdev] Calling functions across modules. And those pesky vectors!

[Christopher Lamb]

On Jan 3, 2008, at 6:14 PM, Danny wrote:

> Before I get started with more questions, thanks for the prompt  
> reply on
> my last set question, that was much appreciated.
>
> First, I found references to lazy inling and optimizations for calling
> functions across modules, but I can't figure out how to do that. If I
> just take a Function* that I got out of one module and call it from  
> the
> other, it doesn't work. What's the general method for dealing with
> interactions between modules? Up until this point, everything I've  
> done
> has been within one module.
>
>
> Second, I was under the impression that vector types were fairly well,
> but I can't seem to get a simple function which takes in and returns
> vectors to work properly. And I don't understand the error. I made a
> simple function which was just supposed to multiply two 3 component
> float vectors and return the result:
>
> //Snip on:
>     VectorType *vType = VectorType::get(Type::FloatTy, 3);
>
>     std::vector<const Type*> Vectors(2, vType);
>     FunctionType *mul_type     = FunctionType::get(vType, Vectors,  
> false);
>     Function* mul              = new Function(mul_type,
> Function::ExternalLinkage, "mul", mod);
>     mul->setCallingConv(CallingConv::C);
>
>     Function::arg_iterator args = mul->arg_begin();
>     Value* x = args++;
>     x->setName("x");
>
> When I run getPointerToFunction I get an abort trap with the message:
> Return operand #1 has unhandled type f32
>
> When I print out the LLVM IR that was produced I get this:
> ; ModuleID = 'test'
>
> define <3 x float> @mul(<3 x float> %x, <3 x float> %y) {
> entry:
>         %result = mul <3 x float> %x, %y                ; <<3 x  
> float>>
> [#uses=1]
>         ret <3 x float> %result
> }
>
> Which seems pretty reasonable to me.
>
> Can anyone help me understand what's going on?

CodeGen for non-power-of-2 vector lengths is not working for any  
target yet, I belive. Try the same thing with a 4-element vector and  
it'll probably work.

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080104/131c5e2c/attachment.html>