Hi, Question 1: Will the new type system allow to incrementally build structs (instead of filling all the fields in one go, as in the example given in <http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt>? Question 2: Will the ocaml bindings to be updated to work with the new type system once the merging of the rewrite to the main branch is done? Thanks very much, N
On Jul 18, 2011, at 9:00 AM, Nicolas Ojeda Bar wrote:> Hi, > > Question 1: Will the new type system allow to incrementally build structs (instead > of filling all the fields in one go, as in the example given in > <http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt>?Nope, a struct either has a body or not. You can't add members to a type incrementally.> Question 2: Will the ocaml bindings to be updated to work with the new type system > once the merging of the rewrite to the main branch is done?That would be great! -Chris
I know this is obvious, but one way to achieve a somewhat equivalent incremental
update mechanism, is to instead incrementally update a container. Once the
container is "finished", the structure type is manifested by
setBody("ArrayRef ver. of
container").
I was surprised how effortless my port from use of opaque to name struct types
was, although I guess this depends on one's milage.
Garrison
On Jul 18, 2011, at 12:00, Nicolas Ojeda Bar wrote:
> Hi,
>
> Question 1: Will the new type system allow to incrementally build structs
(instead
> of filling all the fields in one go, as in the example given in
> <http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt>?
>
> Question 2: Will the ocaml bindings to be updated to work with the new type
system
> once the merging of the rewrite to the main branch is done?
>
> Thanks very much,
> N
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi James, Sorry I missed this. Please send things to the list, not to me directly. On Jul 20, 2011, at 9:52 PM, james woodyatt wrote:> One thing that springs to mind after reading the <http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt> note is that the vocabulary seems a bit confusing. > >> This argues for terminology along the lines of: >> >> Named structs. >> Unnamed structs (named structs with no names) >> Anonymous structs (things like complex, which cannot be cyclic) > > > Unnamed vs. Anonymous... yeesh. Plus: "named structures with no names" is almost pure word salad. I mean, I get that identifiers in LLVM come in "named" and "unnamed" flavors. Still, to someone coming into LLVM for the first time, this will be pretty brain-scroodling. I haven't looked at the trunk branch to see what you actually wrote, but I sure hope you settled on something more coherent. If it's just a matter of tweaking the documentation, then here's what I would propose: > > - "Named" structure type variables, e.g. %struct.foo > - "Unnamed" structures type variables, e.g. %3 > - "Literal" structure type expressions, e.g. { double, double }I like this! It is much better than the names I came up with. Any objections? If not, I'll try to find time in the next couple weeks to "change the world" again to use these names. -Chris
On Thu, Aug 11, 2011 at 1:31 PM, Chris Lattner <clattner at apple.com> wrote:> > - "Named" structure type variables, e.g. %struct.foo > > - "Unnamed" structures type variables, e.g. %3 > > - "Literal" structure type expressions, e.g. { double, double } > > I like this! It is much better than the names I came up with. Any > objections? >Would "identifiers" be a better term than "variables" here? I don't really know, but variables make me think of things that, well, vary. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110811/5e085342/attachment.html>