similar to: [LLVMdev] Parametric polymorphism

On 2009-02-18, at 14:53, DeLesley Hutchins wrote: > On 2009-02-18, at 08:06, Gordon Henriksen wrote: > >> Still, there are a large number of potential foibles here. For >> instance, passing an argument can require platform-specific >> contortions to conform to the platform ABI... > > Are those contortions done by the native code generator back-end, or > are

On Wed, Feb 18, 2009 at 12:32, DeLesley SpamBox <delesley.spambox at googlemail.com> wrote: >> I think the problem is deeper than that, in that LLVM has no official >> concept of a subtype, so I don't see how the idea of polymorphism >> could be defined in it. > > Parametric polymorphism is different from subtype polymorphism; you > can have one without the

> I was thinking of the "T extends Comparable" part, which does involve > subtype polymorphism. Apologies if I'm getting terms mixed up. It was a bad example -- not close enough to actual LLVM. :-) > What do the parametrized types give you that you don't get from using > opaque instead of T? Possibly nothing. I don't really understand the limitations of

> It's done by the front-end. There are a variety of attributes and > mechanisms which are used to convolute data and marshall it through > call sites in an ABI-conformant manner. Oh dear. :-( Do the attributes change depending on the type? I would assume that attributes like "ccc" are type-invariant; i.e. every instantiation should use the C-calling convention, whatever

> I think the problem is deeper than that, in that LLVM has no official > concept of a subtype, so I don't see how the idea of polymorphism > could be defined in it. Parametric polymorphism is different from subtype polymorphism; you can have one without the other. Parametric polymorphism just means that you can use type variables (like T) in the IR, which are later instantiated to

On Wednesday 18 February 2009 20:57:02 DeLesley Hutchins wrote: > > It's done by the front-end. There are a variety of attributes and > > mechanisms which are used to convolute data and marshall it through > > call sites in an ABI-conformant manner. > > Oh dear. :-( I think many people were confused by this at first but an excellent counter example was provided in a

I'm a newcomer to llvm, but what you've done so far is very impressive. Llvm is a godsend to anybody who is attempting to implement their own their own language. :-) My company is considering using llvm as the backend for a small matlab-like language for scientific computation; our other option is MSIL. After reading through the documentation, I noticed that llvm seems to have one major

> I think many people were confused by this at first but an excellent counter > example was provided in a previous thread: C99 ABIs can require that struct > return values are returned via a pointer to a preallocated struct passed as > an auxiliary argument *except* when you're talking about a C99 complex, in > which case the return value is conveyed in a completely different

Why do you say that people who compile, e.g., functional languages would benefit from type variables in LLVM? I like the level the LLVM is at, and would prefer to deal with instantiating parametric polymorphism at a higher level. On Wed, Feb 18, 2009 at 10:43 PM, DeLesley Hutchins <delesley.spambox at googlemail.com> wrote: >> I think many people were confused by this at first but an

> Why do you say that people who compile, e.g., functional languages > would benefit from type variables in LLVM? > I like the level the LLVM is at, and would prefer to deal with > instantiating parametric polymorphism at a higher level. I'm surprised you're happy with a non-polymorphic llvm. Does Cayenne target llvm? Dependent types take polymorphism to new heights -- but

On Wednesday 18 February 2009 23:36:27 DeLesley Hutchins wrote: > > Why do you say that people who compile, e.g., functional languages > > would benefit from type variables in LLVM? > > I like the level the LLVM is at, and would prefer to deal with > > instantiating parametric polymorphism at a higher level. > > I'm surprised you're happy with a

On Wednesday 18 February 2009 21:27:21 DeLesley Hutchins wrote: > Try implementing a generic complex number class in Java, and watch the > two-order-of-magnitude drop in performance on scientific code. Amen. I haven't proven it with a working HLVM yet but I believe LLVM will make it possible (even easy?) to generate extremely performant code from heavily abstracted high-level source.

> The same can be said of closures, garbage collection and a dozen other > features that also cannot feasibly be added to LLVM. > > The only logical solution is to build a HLVM on top of LLVM and share that > between these high-level language implementations. This is an excellent point. You have convinced me. :-) BTW, what garbage collector are you using for your HLVM? You

>> How difficult would it be to add such a capability to llvm? I was thinking >> of marking type variables like T as opaque types for the initial codegen, >> and then writing a custom pass that instantiates them to real types. >> However, I don't know if that would confuse or break other parts of the >> compiler infrastructure; parametric polymorphism is not

On Thursday 19 February 2009 03:31:04 DeLesley Hutchins wrote: > > The same can be said of closures, garbage collection and a dozen other > > features that also cannot feasibly be added to LLVM. > > > > The only logical solution is to build a HLVM on top of LLVM and share > > that between these high-level language implementations. > > This is an excellent point.

Hi Jon, Jon Harrop wrote: > Other people are creating far more bleeding edge VMs (e.g. VMKit) using LLVM's > GC API so they would be much better positioned to discuss the technical > aspects than I am. I would like to hear any status updates they have! > > VMKit uses conservative GCs (Boehm or Mmap2, a GC developed in our lab), so we don't use the GC API. But we are

On Thursday 19 February 2009 13:39:24 Nicolas Geoffray wrote: > Jon Harrop wrote: > > Other people are creating far more bleeding edge VMs (e.g. VMKit) using > > LLVM's GC API so they would be much better positioned to discuss the > > technical aspects than I am. I would like to hear any status updates they > > have! > > VMKit uses conservative GCs (Boehm or

--- generator/API.ml | 1 + generator/API.mli | 1 + generator/C.ml | 14 ++++++++++---- generator/GoLang.ml | 5 +++++ generator/OCaml.ml | 5 +++++ generator/Python.ml | 11 +++++++++-- 6 files changed, 31 insertions(+), 6 deletions(-) diff --git a/generator/API.ml b/generator/API.ml index 0a876c4..b93580d 100644 --- a/generator/API.ml +++ b/generator/API.ml @@ -47,6 +47,7 @@

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

On 9/29/20 6:26 AM, Richard W.M. Jones wrote: > On Mon, Sep 28, 2020 at 05:05:16PM -0500, Eric Blake wrote: >> + "get_meta_context", { >> + default_call with >> + args = [ Int "i" ]; ret = RString; > > Previously we have only used the Int parameter type for things which > are plausibly integers (timeouts, signal numbers). This one really