search for: delesley

...eads to a limited VM. Witness the JVM (only supports Java), or MSIL (designed for C#, with other features tacked on as an afterthought). What you say about maturity and destabilization is probably true, but that's more of a political problem or a manpower problem, not a technical problem. -DeLesley

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 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 st...

...I talk about ``types'', I am referring to low-level llvm types -- scalars, records, pointers, etc. I'm not referring to complex functional types with pattern matching as found in Haskell, or complex OOP classes as found in JVM or .NET with constructors, methods, and all that jazz. -DeLesley

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 fro...

...done in different ways -- compare Java type erasure (use pointers, instantiate nothing), with C++ (instantiate everything), with .Net (instantiate some things). (I don't know how Ocaml does it) It is very difficult to share code between languages if the erasure semantics differ so widely. -DeLesley

...e, well-known, off-the-shelf solutions. Pick one, plug it into llvm, and you have a type system that can compete with the JVM or .NET in terms of functionality, without being OOP centric or sacrificing language neutrality. (System F is low-level -- OOP can be easily implemented on top of it). -DeLesley

...vel language, then it's impossible for the llvm linker, JIT, or optimizers, or code generators to do anything intelligent with them. :-) I don't expect magic. If type specialization is implemented as an IR pass, then why couldn't post-specialization IR optimizations be performed? -DeLesley

...> since you don't need the type information at all once past the > front-end. Yes, and Java generics are dog-slow because they can only use pointers. Try implementing a generic complex number class in Java, and watch the two-order-of-magnitude drop in performance on scientific code. -DeLesley

Why isn't the clang project mentioned anywhere on the main llvm web site? -DeLesley

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 con...

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 perform...

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...

...nvinced me. :-) BTW, what garbage collector are you using for your HLVM? You complain about mono's use of the Boehm-Weiser collector on your blog; but you also said that you assumed an uncooperative environment. I'm not a GC expert, so why are the current GC intrinsics insufficient? -DeLesley

...lass Mix<X> extends X { ... } If I implement Mix as a template, then every instantiation of Mix would generate new code for every method. However, if I simply pass the size of X as a hidden argument to each method, then the code can be generated once, and compiled to a separate library. -DeLesley

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...

...te efficient code. If the actual specialization was encapsulated within a separate pass, then different languages could use whatever technique was most appropriate. Unfortunately, different techniques are not binary compatible, so that would make it hard to design a universal type system. :-( -DeLesley

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...

...Buildbot URL: http://lab.llvm.org:8011/ > > Buildslave for this Build: sschiffli1 > > Build Reason: scheduler > Build Source Stamp: [branch trunk] 162350 > Blamelist: aaronballman,ahatanak,alexfh,anithab,asl,baldrick,bwilson,chandlerc,chapuni,criswell,ctopper,d0k,dblaikie,ddunbar,delesley,dgregor,djasper,dyatkovskiy,echristo,efriedma,evancheng,fjahanian,gps,gribozavr,grosbach,grosser,hanm,hans,hliao,jacksprat,jaykang10,jrose,jush,kcc,klimek,kremenek,matthewbg,mcrosier,mspencer,nadav,nicholas,panzer,pranavb,rafael,rdivacky,resistor,rjmccall,rsmith,rtrieu,spop,spyffe,stoklund,tbrethou...

...gt; > Build Reason: scheduler > Build Source Stamp: [branch trunk] 189664 > Blamelist: aaronballman,ab,adibiagio,adrian,ahatanak,ajbernal,akaylor,akirtzidis,alexfh,arnolds,arsenm,atrick,ayartsev,bwilson,carlokok,cdavis,chandlerc,chapuni,compnerd,ctopper,d0k,daenzer,dblaikie,ddunbar,delena,delesley,dgregor,dirty,djasper,dsanders,dvyukov,echristo,efriedma,enderby,enea,eugenis,faisalv,fangism,filcab,fjahanian,gribozavr,grosbach,hanm,hans,haoliu,hfinkel,jacksprat,jdennett,jholewinski,jimcownie,joerg,joey,jrose,jtsoftware,kevinqin,klimek,kremenek,kuba,labath,lattner,lhames,logan,lvoufo,majnemer,m...

On Fri, Nov 8, 2013 at 8:44 AM, Filip Pizlo <fpizlo at apple.com> wrote: > Is the expectation that to utilize this metadata an optimization pass > would have to inspect the body of @f and reason about its behavior given > <args>? > > > Yes. > > > If so, then I think this is pretty bad. If we ever want to parallelize > function passes, then they can't