similar to: [LLVMdev] MutexGuard and MutexLocker

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

On Tue, 2004-04-13 at 21:58, Reid Spencer wrote: > On Tue, 2004-04-13 at 19:10, Chris Lattner wrote: > This is completely opposite the way I work. If I had CVS access, I would > do the whole change in a branch. This would include fixing all > makefiles, moving all files, creating/fixing configure scripts, and > running all regressions to make sure it worked. I would then check in

<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 Fri, 2003-11-14 at 10:56, Alkis Evlogimenos wrote: > On Friday 14 November 2003 12:45 pm, Brian R. Gaeke wrote: > > > So what they call "system" headers are basically installed > > > headers and user headers are internal ones. In the context of llvm every > > > header that is under inlcude is a "system" header (because when we write > >

On Friday 14 November 2003 01:22 pm, Reid Spencer wrote: > There is no separation of headers and cpp files. When I specify my > makefiles, I indicate which headers are public (installable) and which > are private (not installed). IMO it is better to include with "" internal header files that are never installed as is the case with all headers under lib. It makes file

On Sun, 2004-09-26 at 12:42, Paolo Invernizzi wrote: > Attached to this email you can find it and a new series of patches > against current CVS, that I hope are pretty safe. Paolo, I applied most of your patches to cvs. I didn't apply the patches for things under lib/Support. I will leave that to Reid (if you can resend those to this list it would be great). Here is the list of the

On 4/25/06, Archie Cobbs <archie at dellroad.org> wrote: > Alkis Evlogimenos wrote: > > On 4/25/06, Archie Cobbs <archie at dellroad.org> wrote: > >> Motivation: Java's "first active use" requirement for class initialization. > >> When invoking a static method, it's possible that a class may need to > >> be initialized, However,

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 Tue, 2004-04-13 at 19:10, Chris Lattner wrote: > Yes, definitely. I think the right way to do this is to make it be as > incremental as possible. In particular, the biggest benefit will be to > get llvm/test/Programs into a seperate tarball from the main LLVM tree, as > it is big and will (hopefully!) keep getting bigger. There are several > tasks that can be done

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 Sun, 2006-04-23 at 09:43 -0500, Archie Cobbs wrote: > Hi, > > I'm just learning about LLVM (really interesting) and have some newbie > questions. Feel free to ignore or disparage them if they're inappropriate :-) No worries. > > My area of interest is using LLVM in a Java JVM setting. These are > just some random questions relating to that... > > 1. What

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

On Thu, 2004-07-08 at 07:07, Vladimir Prus wrote: > Vladimir Prus wrote: > > Vladimir Prus wrote: > > > The above-mentioned test contains this: > > > > > > long B53 = - (1LL << 53); > > > > > > strictly speaking, this is not correct code. The C standard says about > > > shift: "if the value of the first operator is ... or

LLVMers, I'm running into a fair bit of confusion as I start to *use* LLVM to build my own compiler. The issues relate to what is in a given .a or .o file, why linking takes so long, and getting LLVM header files to include correctly, and the lack of viable "install" target. I'll deal with each of these in turn: For my own project, I've added an AC_CHECK_LIB line to check

Hi, I'm just learning about LLVM (really interesting) and have some newbie questions. Feel free to ignore or disparage them if they're inappropriate :-) My area of interest is using LLVM in a Java JVM setting. These are just some random questions relating to that... 1. What is the status of the LLVM+Java effort? Is it GCJ-specific? Is there a web page? I found one link via google

On Thursday 21 October 2004 01:54, Vladimir Prus wrote: > On Wednesday 20 October 2004 12:01, Reid Spencer wrote: > > I'm re-thinking my penchant for automake. automake is great for many > > standard applications that just need to get portable makefiles up and > > running quickly. However, it turns out that LLVM is "different enough" > > from a standard

On 08/09/05, Alkis Evlogimenos <evlogimenos at gmail.com> wrote: > to those coalesced registers, it is logical that noone will ever query > the liveness of those registers (unless there is a bug somewhere in the Indeed the coalesced registers may logically not be queried since they do not appear in any operand list of the machine code, but the VarInfo::DefInst in VirtRegInfo of the

On 08/09/05, Alkis Evlogimenos <evlogimenos at gmail.com> wrote: > representative register (found using a union find algorithm). Note that > the representative register could be a real register if we ever joined > an interval of a real register with one of a virtual register (and this > real register will be the representative register of the set of > intervals joined

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