Displaying 3 results from an estimated 3 matches for "builtin_complex_add".
2007 Nov 06
1
[LLVMdev] Passing and returning aggregates (who is responsible for the ABI?)
...egisters,
> but that a struct with two doubles in it should be returned in memory.
Even today, that must be special cased, i.e. the IR needs to be
distinct between the two cases. As I understand it, the following is
already legal, since vectors are first class:
declare <2 x double> @builtin_complex_add (<2 x double>, <2 x double>)
That would be the built-in complex type. The user-defined complex-in-
struct type could be one of the following depending on the ABI:
declare void @user_complex_add (double, double, double, double,
{double, double} *)
declare void @user_complex_add ({...
2007 Nov 06
0
[LLVMdev] Passing and returning aggregates (who is responsible for the ABI?)
> I'm trying to port the XL compiler (http://xlr.sf.net) to use the
> LLVM back-end. So far, little trouble doing so. But there is one
> aspect of the semantics of the LLVM IR that surprises me. Why are the
> call, declare and define "halfway through" ABI conventions?
Hrm?
> I think it's the right thing to have a single high level node for
> each call, as
2007 Nov 06
4
[LLVMdev] Passing and returning aggregates (who is responsible for the ABI?)
Hello,
I'm trying to port the XL compiler (http://xlr.sf.net) to use the
LLVM back-end. So far, little trouble doing so. But there is one
aspect of the semantics of the LLVM IR that surprises me. Why are the
call, declare and define "halfway through" ABI conventions?
I think it's the right thing to have a single high level node for
each call, as opposed to separate