similar to: [LLVMdev] "Broken" link in Kaleidoscope sample

> Nope, types are immutable once created. The only thing you can do is "refine" opaque types to other types. There is a section in the programmer's manual on this: > http://llvm.org/docs/ProgrammersManual.html#TypeResolve > > -Chris So I succeeded in using a "PATypeHolder" for the "opaque" type, define a Type* with PointerType::getUnqual, prepare

On Jun 14, 2010, at 1:22 PM, Stéphane Letz wrote: > Hi, > > We build a type with StructType::get(fModule->getContext(), fDspFields, false); with a fDspFields (std::vector<const llvm::Type*> fDspFields;) that is not yet completely known when we have to build the type. It is possible to add fields in a already build type? Nope, types are immutable once created. The only

On Jun 15, 2010, at 11:51 AM, Stéphane Letz wrote: >> Nope, types are immutable once created. The only thing you can do is "refine" opaque types to other types. There is a section in the programmer's manual on this: >> http://llvm.org/docs/ProgrammersManual.html#TypeResolve >> >> -Chris > > > So I succeeded in using a "PATypeHolder"

Nope, it seems that the code is correct after all. Perhaps a bit unclear, but correct. So shame on me! Cheers, Mikael ---------- Forwarded message ---------- From: Mikael Lyngvig <mikael at lyngvig.org> Date: 2012/5/14 Subject: Tiny bug in Kaleidoscope sample To: llvmdev at cs.uiuc.edu Hi, As far as I can tell, there's a tiny error in the sample code for the Kaleidoscope

I'd like to be able to make use of a structure type and its fields before it is completely defined. To be specific, let me ask detailed questions at various stages in the construction of a recursive type. I copy from http://llvm.org/docs/ProgrammersManual.html#TypeResolve // Create the initial outer struct PATypeHolder StructTy = OpaqueType::get(); Is it possible to declare

On Sep 29, 2008, at 6:18 AM, Christian Plessl wrote: > On 29.09.2008, at 11:53, Jonathan S. Shapiro wrote: >> Watching this thread, it occurs to me that the "V" in "LLVM" is >> creating >> confusion. So far as I know, LLVM is the first project to use >> "virtual" >> to refer to the instruction set of the intermediate form. I >>

Hi Chris, Thanks for the supporting words! I'm pushing the document both for egoistic motives (like so many others, I'll learn a ton from this document) and for altruistic motives - the easier it is to implement a new language, the more interesting and highly well-thought out languages we will see in the future. And I see it as my purpose, as a mostly black-box user of LLVM, to enhance

On Fri, Sep 12, 2008 at 9:35 AM, Hendrik Boom <hendrik at topoi.pooq.com> wrote: > I'd like to be able to make use of a structure type and its fields before > it is completely defined. To be specific, let me ask detailed questions > at various stages in the construction of a recursive type. I copy from > > http://llvm.org/docs/ProgrammersManual.html#TypeResolve > >

The link to the next chapter in the navigation list at the top of this page of the OCaml Kaleidoscope tutorial goes to the C++ version: http://llvm.org/docs/tutorial/OCamlLangImpl3.html. The link to chapter 8 in the first chapter is broken: http://llvm.org/docs/tutorial/OCamlLangImpl1.html#intro. It links to the unvavailable page http://llvm.org/docs/tutorial/OCamlLangImpl8.html. I think it

On Wed, Dec 4, 2013 at 12:54 AM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi Chris, > > Thanks for the supporting words! I'm pushing the document both for > egoistic motives (like so many others, I'll learn a ton from this document) > and for altruistic motives - the easier it is to implement a new language, > the more interesting and highly well-thought

Hi guys, I have begun writing on a new document, named "Mapping High-Level Constructs to LLVM IR", in which I hope to eventually explain how to map pretty much every contemporary high-level imperative and/or OOP language construct to LLVM IR. I write it for two reasons: 1. I need to know this stuff myself to be able to continue on my own language project. 2. I feel that this needs to

Hi, It will probably take a few weeks or a month before the "Mapping High-Level Constructs to LLVM IR" document is ready for prime time. Until then, you can review and study it at this URL: https://github.com/archfrog/llvm-doc/blob/master/MappingHighLevelConstructsToLLVMIR.rst Please notice that I specifically do not advocate reviewing the document for a week or two. But feel free

Hi, I am building a new JIT compiler for Lua (actually a derivative of Lua), and am planning to use LLVM for this. I have trying out some basic functions using LLVM 3.5.1. I have been puzzled by one aspect of the MCJIT versions of the Kaleidoscope sample, and would hugely appreciate some insight. Can a single MCJIT instance be used to manage several modules? Why is a separate MCJIT instance

On Nov 28, 2013, at 6:07 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi, > > It will probably take a few weeks or a month before the "Mapping High-Level Constructs to LLVM IR" document is ready for prime time. Until then, you can review and study it at this URL: > >

Thanks, you have a lot of valid points there. I have myself long ago abandoned the path of using C as a backend language due to the very factors you mention. However, as I said, the document was put together in 30 minutes. Not exactly ready for prime time :-) I do agree that all of the things you mention should be described, including Lambdas, closures, and generators, but I must admit up

Yes, it is sort of scary that there seems to be no definite resource to consult for information on especially advanced OOP things. I have something like 20 compiler books on my shelves and yet none of them mention a single word on how to implement multiple inheritance, exception handling, or interfaces. It seems like they are all happy about presenting a subset of Pascal, or Java, with an

On Nov 11, 2007, at 2:41 PM, Kelly Wilson wrote: > Hey Chris: > > Here are the diffs for the next few chapters of the tutorial that I > have > edited. Nice! You are an excellent editor, I'm impressed. I committed these without any changes here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071112/055566.html Thank you for the help with this. > Please

That reminds me: Do the web documents reside in a repository somewhere or should I just grab them using wget? 2012/6/14 Michael Spencer <bigcheesegs at gmail.com> > On Wed, Jun 13, 2012 at 4:02 PM, Mikael Lyngvig <mikael at lyngvig.org> > wrote: > > If nobody else is doing it, I can translate the FAQ into Sphinx as I'd > like > > to begin gradually extending

Have I correctly inferred below, how I build IR and debug info for a function type and a function (value), in particular, how to supply the names of the formal parameters? To create a function in llvm IR and give names to its formal parameters, I must: 1. Build a LLVMTypeRef for the type of each formal and the function result. 2. Build a function type using LLVMFunctionType, from the results of

HI Dibyendu, A single MCJIT instance can notionally manage multiple modules, but there are caveats (which I'm afraid I don't remember off the top of my head) that make it unattractive in practice. I believe most clients opt for something like the ExecutionEngine-per-Module model used in the Kaleidoscope tutorials. As Dave mentioned, I'm also working on some new JIT APIs (Orc) that