similar to: [LLVMdev] global register allocators and spill code

I'm a taking a compiler course and I'm supposed to implement a scheduler for the LLVM compiler and comapre its persformance to the existing one used by LLVM-gcc. I need some help understanding what is really happening in LLVM-gcc. In CodeGen/SelectionDAG/ I can see four different Schedulers, which one is used by LLVM? Can you give a hint on where/how to add a new scheduler and test

Hello LLVMers! I recently added a generic machine rewriter/spiller that global register allocator writers may find useful. The API provided is the free function: void eliminateVirtRegs(MachineFunction&, const VirtRegMap&) declared in lib/CodeGen/VirtRegMap.h and implemented in lib/CodeGen/VirtRegMap.cpp. This function rewrites the machine code of MachineFunction to eliminate

<algorithm> works too. On Fri, 24 Sep 2004 10:09:21 -0500 Alkis Evlogimenos <alkis at cs.uiuc.edu> wrote: > On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > > Jeff Cohen wrote: > > > > >But I compiled that under vc7.1 as it was! > > > > > > > > ;-(( > > > > Probably is an implicid includes, but I'm using the

On Sun, 28 Dec 2003, Anshu Dasgupta wrote: > CodeGen/RegAlloc/PhysRegAlloc.cpp implements a graph coloring register > allocator for the Sparc back end. It requests target machine register > information via a call to getRegInfo() which returns a class > TargetRegInfo containing the required information. For the x86 target > machine, this interface has not been implemented. Is an

In case anyone's interested, I followed up in the linux-nfs mailing list: https://marc.info/?l=linux-nfs&m=156887818618861&w=2 Thanks, Alkis On 9/15/19 10:51 AM, Alkis Georgopoulos wrote: > I think I got it. > > Both nfsmount and `mount -t nfs` now default to rsize/wsize = 1 MB. > By lowering this to 32K, all issues are gone, even with the default > timeo=7. And

On Thu, May 05, 2005 at 03:46:58AM -0400, Alexander Friedman wrote: > On May 5, Misha Brukman wrote: > > To the best of my knowledge, this has not been done and no one has > > announced their intent to work on it, so if you are interested, > > you'd be more than welcome to do so. > > My C++ knowledge is completely non-existant, but so far I've had a >

On May 5, Misha Brukman wrote: > Maybe we can use you for a testimonial... :) Certainly. > > Tail Call Elimination: > > > > I've read over the "Random llvm notes", and see that you guys have > > though about this already. > > > > However, the note dates from last year, so I am wondering if there is > > an implementation in the works.

On 29 Apr 2006 20:38:58 -0600, Tom Tromey <tromey at redhat.com> wrote: > >>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: > > >> In the JIT, devirtualization looks doable, though somewhat fiddly. At > >> least, that is true for straightforward things like calls to methods > >> in final classes, or calls to

On Sun, 23 Apr 2006, Reid Spencer wrote: >> Has it been hooked up to a JVM? If so, how and which ones? > > I think the point of llvm-java was to avoid a JVM. That is, it converts llvm-java is the JVM. > either Java source or Java bytecode into equivalent LLVM bytecode. I llvm-java only supports input from Java bytecode. > think the big thing lacking so far are the Java

On Sat, 2005-08-27 at 11:47 -0700, Reid Spencer wrote: > Alkis Evlogimenos wrote: > > It seems that these two classes are the same... Maybe they should be > > merged into 1 class? > > > I think you're looking at something old. MutexLocker doesn't exist any more. llvm/Support/ThreadSupport.h is not generated anymore? -- Alkis

Alkis Evlogimenos wrote: >Is there a chance you can try cvs? I would be interested to >get a simplified test case where the allocator breaks. A lot of >improvements went into the x86 backend since 1.2 and we currently have >no test cases where the allocator breaks today. > > I updated and recompiled and the error is still there. It turns out that I cannot use the bugpoint

Chris Lattner wrote: >> I think the point of llvm-java was to avoid a JVM. That is, it converts > > llvm-java is the JVM. > >> either Java source or Java bytecode into equivalent LLVM bytecode. I > > llvm-java only supports input from Java bytecode. > >> think the big thing lacking so far are the Java library and support for > > llvm-java uses

I can't explain why 700 msecs aren't enough to avoid timeouts in 100 Mbps networks, but my tests verify it, so I'm writing to the list to request that you increase the default timeo to at least 30, or to 600 which is the default for `mount -t nfs`. How to reproduce: 1) Cabling: server <=> 100 Mbps switch <=> client Alternatively, one can use a 1000 Mbps switch and

Alkis Evlogimenos wrote: > On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > > Hello! > > Is there an (semi)automatic way to save registers used by a function? For > > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For > > now I just emit huge prologue code to push them all to stack -- even if > > they are not modified at all. > > >

On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > Jeff Cohen wrote: > > >But I compiled that under vc7.1 as it was! > > > > > ;-(( > > Probably is an implicid includes, but I'm using the STLPort standard > library for LLVM (because it's not possible to use hash_map and hash_set > of microsoft) std::remove is in <algorithm> --

It seems that these two classes are the same... Maybe they should be merged into 1 class? -- Alkis

Actually, <algorithm> is not correct. This remove is in stdio.h and io.h in VC7.1. It removes a file, not elements from a collection. The proper solution is to not use remove at all and use Path::destroy_file(). On Fri, 24 Sep 2004 08:09:37 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > <algorithm> works too. > > On Fri, 24 Sep 2004 10:09:21 -0500 > Alkis

On Wed, 2004-06-09 at 05:26, Vladimir Prus wrote: > Alkis Evlogimenos wrote: > > On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > > > Hello! > > > Is there an (semi)automatic way to save registers used by a function? For > > > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For > > > now I just emit huge prologue code to push

On Wed, Apr 21, 2004 at 11:01:48AM +0200, Finn S Andersen wrote: > For some of the benchmarks the linear scan regalloc > works. When it does, results are in the x1.0 - 1.5 > range. Unfortunately, the linear scan allocator breaks > on most of my code. Is there a chance you can try cvs? I would be interested to get a simplified test case where the allocator breaks. A lot of

On Thu, May 06, 2004 at 04:06:27PM +0200, Finn S Andersen wrote: > Chris Lattner wrote: > > >I think that we should switch to C constants in this case. Can you try > >#include <math.h> and use HUGE_VAL instead? > > > It works: > > [finna at coplin11 ~/test]$ cat tst.cpp > #include <limits> > #include <iostream> > #include