search for: t_classif

...o check this > in as is. However, I'd be interested in any feedback you're willing > to give. Looking good so far, some thoughts: The LangRef.html patch looks great. One thing that I notice is that the term 'aggregate' is not defined anywhere. Please add it to the #t_classifications section and change the insert/extractvalue instructions to refer to that type classification instead of enumerating the options. The ConstantUnion ctor or ConstantUnion::get should assert that the constant has type that matches one of the elements of the union. @@ -928,7 +949,7 @@...

...gt; However, I'd be interested in any feedback you're willing to give. >> > > Looking good so far, some thoughts: > > The LangRef.html patch looks great. One thing that I notice is that the > term 'aggregate' is not defined anywhere. Please add it to the > #t_classifications section and change the insert/extractvalue instructions > to refer to that type classification instead of enumerating the options. > > The ConstantUnion ctor or ConstantUnion::get should assert that the > constant has type that matches one of the elements of the union. > >...

...gt; However, I'd be interested in any feedback you're willing to give. >> > > Looking good so far, some thoughts: > > The LangRef.html patch looks great. One thing that I notice is that the > term 'aggregate' is not defined anywhere. Please add it to the > #t_classifications section and change the insert/extractvalue instructions > to refer to that type classification instead of enumerating the options. > > The ConstantUnion ctor or ConstantUnion::get should assert that the > constant has type that matches one of the elements of the union. > >...

> > 2) add a "byref" mark in the pointer argument. > > I think you mean "bycopy" or "byval" here. Yes, good catch. > > 3) Have llvm-gcc create a copy before calling the function. > > Don't forget that the function may be called by code that > was not compiled by LLVM. That's why we have to pay attention > to the ABI! Solution

OK here's the patch for real this time :) On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test "union.ll" > does not work, so you probably don't want to check this in as is. However, > I'd be interested in any feedback you're willing to give. > > -- > -- Talin

Here's a work in progress of the union patch. Note that the test "union.ll" does not work, so you probably don't want to check this in as is. However, I'd be interested in any feedback you're willing to give. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 6 nov. 07, at 06:17, Chris Lattner wrote: >> But then, why refuse aggregates as input or output of a call? What is >> the rationale? > > Because LLVM has no notion of aggregates as "values" that can be > passed around as atomic units. This is a very important design point, > and has many useful values. I see. You explained one of them in a message on the XL

...rested in any feedback you're willing to give. >>> >> >> Looking good so far, some thoughts: >> >> The LangRef.html patch looks great. One thing that I notice is that the >> term 'aggregate' is not defined anywhere. Please add it to the >> #t_classifications section and change the insert/extractvalue instructions >> to refer to that type classification instead of enumerating the options. >> >> The ConstantUnion ctor or ConstantUnion::get should assert that the >> constant has type that matches one of the elements of the...