Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] What happened to llvm::PerformTailCallOpt?"
2010 Feb 18
0
[LLVMdev] What happened to llvm::PerformTailCallOpt?
On Feb 18, 2010, at 2:12 AM, Jon Harrop wrote:
>
> I'm just trying to test HLVM with the latest SVN of LLVM and discovered that
> llvm::PerformTailCallOpt has disappeared from the code but it is still
> referred to from LangRef.html.
>
> Where did it go?
It got renamed to GuaranteedTailCallOpt, to better reflect what it actually represents.
--Owen
-------------- next
2009 Jan 04
3
[LLVMdev] HLVM
What happened to the HLVM project? I understand it was intended to be a
high-level VM specifically for dynamic languages and this post indicates that
it was integrated into the LLVM project last year:
http://www.nabble.com/NEWS:-HLVM-merges-with-LLVM-td9627113.html
But I cannot find any code in LLVM that looks like it would have come from
HLVM.
--
Dr Jon Harrop, Flying Frog Consultancy
2009 Jun 18
0
[LLVMdev] ML types in LLVM
On Tuesday 16 June 2009 15:44:04 Aaron Gray wrote:
> Jon Harrop wrote:
> >Even if this puts LLVM at an unfair disadvantage, I think you will find
> >that
> >LLVM will thrash MLton's current x86 backend anyway.
> >
> >I did some benchmarking on HLVM and found that it was often several times
> >faster than OCaml when the GC is not the bottleneck:
> >
2009 Jun 24
2
[LLVMdev] Garbage collection implementation
Jon Harrop wrote:
> The simplest way is surely to reuse HLVM because it provides
everything you
> need and is even written in the right language! ;-)
Is there a web page with HLVM docs? There's a README.txt in the
subversion repository:
https://llvm.org/svn/llvm-project/hlvm/trunk/README.txt
which says:
HLVM comes with documentation in HTML format. These are provided in
2009 Mar 10
2
[LLVMdev] Stack smashing
Someone is trying to work on HLVM with me but they're hitting a problem that
we have not been able to resolve. Specifically, GCC seems to be performing
some kind of sanity check for "stack smashing" and is calling abort because
it is unhappy with something that the code is doing. However, I am not sure
what and cannot reproduce the problem.
The stack trace they have given me is:
2009 Jun 16
2
[LLVMdev] ML types in LLVM
>On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote:
>> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote:
>> > Is this really a problem for MLton? I think you only get less precise
>> > alias analysis, and that's it.
>>
>> Correct. However, I want a fair comparison between LLVM performance
>> and the native x86
2010 Feb 17
1
[LLVMdev] LLVM-OCaml Bindings Tutorial (2.6-2.7)
On Tue, Feb 16, 2010 at 2:47 AM, Jon Harrop <jon at ffconsultancy.com> wrote:
> On Tuesday 16 February 2010 03:51:00 Jianzhou Zhao wrote:
>> Does anyone know if there is any realistic project using LLVM-OCaml
>> Bindings?
>
> I've written a VM in OCaml built upon LLVM using LLVM's OCaml bindings:
>
> http://www.ffconsultancy.com/ocaml/hlvm/
>
> There
2009 Jun 18
2
[LLVMdev] Garbage Collection Project
On Thursday 18 June 2009 12:28:57 Cory Nelson wrote:
> I'm also curious what language uses this and why it is useful :)
HLVM is intended to be a general-purpose VM rather than a particular language.
> Also, things like this would make lock-free algorithms difficult or
> impossible.
True. Perhaps that is a good argument for providing both kinds. However, nulls
are certainly more
2009 Jan 04
0
[LLVMdev] HLVM
On Sun, Jan 4, 2009 at 2:36 PM, Jon Harrop <jon at ffconsultancy.com> wrote:
(...)
> But I cannot find any code in LLVM that looks like it would have come from
> HLVM.
Don't know about the status of the project, but the code seems to be here:
http://llvm.org/viewvc/llvm-project/ (in directory "hlvm")
Regards,
Kevin André
2009 Jun 18
0
[LLVMdev] Garbage Collection Project
>
> That is similar to the approach I used, although HLVM provides a pointer
directly to the type, saving you a single hop.
I'm not so sure that is a very good reason, depending on your implementation
data structures that are fundamental to the type system of the virtual
machine use custom allocators so the extra hop carries little to no expense.
I would not have considered it had I
2010 Jan 04
3
[LLVMdev] Tail Call Optimisation
On 04/01/2010, at 3:01 PM, Jon Harrop wrote:
> On Monday 04 January 2010 01:12:55 Simon Harris wrote:
>> I'm investigating "improving" the TCO facilities in LLVM to provide for
>> "hard" tail calls. Specifically, this would involve extending the existing
>> implementation to discard the stack frame for the caller before executing
>> the callee. I
2009 Jan 25
2
[LLVMdev] OCaml Journal article: Building a Virtual Machine with LLVM
Following on from the success of our previous OCaml Journal articles covering
LLVM, we have begun a series dedicated to the design and implementation of
high-level languages using LLVM. In particular, these new articles are more
pragmatic in nature and go beyond describing working compilers to also
discuss testing, debugging and the performance of LLVM-based compilers.
The first article in
2010 Jan 04
0
[LLVMdev] Tail Call Optimisation
On Monday 04 January 2010 03:33:06 Simon Harris wrote:
> On 04/01/2010, at 3:01 PM, Jon Harrop wrote:
> > I am certainly interested in tail calls because my HLVM project relies
> > upon LLVM's tail call elimination. However, I do not understand what tail
> > calls LLVM is not currently eliminating that you plan to eliminate?
>
> Mutual recursion for a start:
>
2009 Apr 05
1
[LLVMdev] Suggestion for VM porting to LLVM
Hi Jon,
I've read your articles about HLVM, and that was one of the reasons
that convinced me to try out LLVM. Actually my VM has been implemented
in C++, but as long as it is not extremely complex, I might port it to
OCaml that sounds more compact for this kind of programs. Did you find
any significant performance loss when using OCaml over C++ ? Runtime
performance is quite
2012 Feb 29
1
[LLVMdev] Tail Call Optimization
Hello,
I started off trying to test HLVM
(http://www.ffconsultancy.com/ocaml/hlvm/) in a freshly compiled
LLVM3.0,
and found a few errors have crept into LLVM between revisions 2.7 and 2.8.
System info:
2.6.31-23-generic #75-Ubuntu SMP x86_64 GNU/Linux, oprofile version
0.9.3-1.1ubuntu2_amd64
HLVM uses the following code to set "guaranteed" tail call optimization:
<code>
2010 Feb 16
0
[LLVMdev] LLVM-OCaml Bindings Tutorial (2.6-2.7)
On Tuesday 16 February 2010 03:51:00 Jianzhou Zhao wrote:
> Does anyone know if there is any realistic project using LLVM-OCaml
> Bindings?
I've written a VM in OCaml built upon LLVM using LLVM's OCaml bindings:
http://www.ffconsultancy.com/ocaml/hlvm/
There are at least two other significant users of LLVM's OCaml bindings,
AFAIK.
> How is the performance?
Performance
2010 Dec 01
2
[LLVMdev] Tail calls not working with LLVM 2.8
I just upgraded HLVM from LLVM 2.7 to 2.8 and started seeing stack overflows
so I think TCO isn't working. Have there been any obvious changes that would
cause this?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com
2009 Mar 10
0
[LLVMdev] Stack smashing
>From a cursory glance, it looks like something is messing with the
stack canarys. Probably a stack buffer overflow.
On Tue, Mar 10, 2009 at 11:41 PM, Jon Harrop <jon at ffconsultancy.com> wrote:
>
> Someone is trying to work on HLVM with me but they're hitting a problem that
> we have not been able to resolve. Specifically, GCC seems to be performing
> some kind of
2009 Feb 19
2
[LLVMdev] Parametric polymorphism
> 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
2009 Apr 04
0
[LLVMdev] Suggestion for VM porting to LLVM
On Saturday 04 April 2009 09:20:21 Gabriele Farina wrote:
> - generate IR from my complier;
> - build a VM that converts at runtime my bytecode to IR and executes it;
>
> I largely prefer the second option because it would be great if I can
> continue to use to old programs without having to recompile them.
>
> Which approach do you suggest ? are there any alternatives ?