similar to: [LLVMdev] Assorted notes on garbage collection with LLVM

Hi Mike, On 2013-08-02 18:26, Michael Lewis wrote: > I've been working recently on a precise garbage collector which runs > alongside native code JITted by LLVM. Today marks the first time the > GC has passed its entire test suite as well as extensive soak tests in > non-trivial programs. I'm glad to hear that you solved the issues you described in your last mail. How did you

Hi all, I would like to implement GC for a language supporting multiple threads. There will be no shared state between threads as communication will be based on message passing. I do not care much about performance. The priority for me is to get things working. I have read LLVM guide on writing GC: http://llvm.org/docs/GarbageCollection.html. Shadow stack approach looks very promising. The

>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

Hi, I'm trying to autotune a good sequence of IR optimization passes and I seem to run into segfaults in opt (in LLVM5) with certain pass orderings. Is this expected behavior? If so, what would be the recommended way of determining pass dependencies so that I can encode them into the tuner? The test program can be found here: https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95

On Fri, Sep 8, 2017 at 9:00 AM Adrian Prantl <aprantl at apple.com> wrote: > > > Eventually, some tests will inevitably need to Windows or Posix > specific, so you're going to have to have all this extra stuff (the new > substitutions, the different command lines, the custom output formats, > etc. So I think something like this provides maximal encouragement of >

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

Hello, I have a patch that: 1. Allows gccld to link shared libraries natively.. 2. Passes along -rpath and -soname to the native linker... 3. Fixes a bug where the bytecode files were kept around after native linking... 4. Removes a now unnecessary warning for native linking... The result is that we are >' '< close to having Qt4 both compile *and* link with the LLVM toolchain.

On Sun, 20 Feb 2005 19:42:34 -0500, Adam Treat wrote: > The result is that we are >' '< close to having Qt4 both compile *and* link > with the LLVM toolchain. Wow, cool! Mind if I ask what is motivating this work? thanks -mike

I have discovered a few oddities with --relative in the latest development rsync (from git, yay!): #1. Junk in the middle of a source argument leads to duplicate entries in the file list: $ mkdir src src/D $ rsync-dev -ni -rR ././src/.//.//.//.//.//.//.//./D/ dest/ cd+++++++++ src/ cd+++++++++ src/./ cd+++++++++ src/ cd+++++++++ src/./ cd+++++++++ src/ cd+++++++++ src/./ cd+++++++++ src/

Cristian Rodr?guez wrote: > The following changes since commit b78d8e4db10e57b8d82bb82e4e3662d5dedd7255: > > FLAC__bitmath_ilog2,FLAC__bitmath_ilog2_wide,COUNT_ZERO_MSBS: add gcc > specific optimizations (2012-03-28 15:43:48 -0300) > > are available in the git repository at: > > git://github.com/crrodriguez/flac.git master > > for you to fetch changes up

El 30/03/12 07:14, Erik de Castro Lopo escribi?: > * 7077ba8be2.. Use a single source-code wide definition of min() and max() > > I like the idea of this commit but don't understand why it modifies > configure.ac. I also don't think the FLAC_SAFE_MIN/MAX defintions > belong in the file include/FLAC/export.h which is a public header file. > Instead, this

I've just finished compiling OpenSSH version 2.1.1p4 for Red Hat Linux 6.2 (i386) with recent patches, using OpenSSL version 0.9.5a, which was compiled to use RSAREF. There are a couple of issues I noticed immediately: 1. The ssh-agent program can only store RSA keys, not DSA keys. 2. Only ssh-add knows to invoke ssh-askpass (if it is not attached to a tty and DISPLAY is set).

I would really like to try out the features in the patch above. But I can't ever seem to get the resulting omindex.cc to "make". I tried updating to rev 10801 from the SVN then run /bootstrap but then I seem to get errors compiling everything when I try and do "make" (I'm using ubuntu 8.10). So I thought I'd try an apply the patch to the latest stable version

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 codegen. If I don't give LLVM the same information the x86 codegen has, it's an unfair comparison.

*This message was transferred with a trial version of CommuniGate(tm) Pro* I'm trying to put togther a starting list of patches required to get 3.7.1p2 working in our enviroment. I'm pretty sure I need the following at minimum but would like guidance about a couple of them and direction on a couple unanswered questions. I've spent most of the morning trolling the archives, but I

Hello everyone, I just thought I would let people here know that ldc (llvm backend for the D Programming Language) is getting pretty usable (a few larger libraries compile) and it now has x86-64 support added. I decided to run some timings on some D and C++ code to compare ldc to dmd (the mainline compiler), gdc (the gcc based D compiler) and g++. I used a ray tracing program found in this

I have a significant chunk of notes from my experience with garbage collector integration with LLVM that I'd be happy to contribute to this effort. The original notes live here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme I imagine it would be preferred if that document was formatted and edited to match the existing efforts; I'll try and start converting it over

The release of a new code generator in Mono 2.2 prompted me to benchmark the performance of various VMs using the SciMark2 benchmark on an 8x 2.1GHz 64-bit Opteron and I have published the results here: http://flyingfrogblog.blogspot.com/2009/01/mono-22.html The LLVM results were generated using llvm-gcc 4.2.1 on the C version of SciMark2 with the following command-line options: llvm-gcc

This series makes several enhancements to tests for v2v conversion of Windows guests. Specifically, it - adds a number of files which imitate the stuff that is supposed to be present on the host when the actual conversion is performed, but may not be there when the tests are run. This includes certain tools and virtio drivers - fixes the test for windows conversion to actually

Hi Philip, Thanks for your great list of ideas for the document! I don't really have a scope for the document beyond: If it something that requires mapping from high-level to LLVM IR, I think it should go into the document. I started out using C++ examples because many people know C++. I am personally mostly an advocate of statically checked languages but I don't see that as a reason