similar to: [LLVMdev] [patch] native AMD64 support

On Wed, 2004-12-22 at 22:40, Misha Brukman wrote: > If you want to work on something, getting LLC to produce AMD64 code > would be the first step, and getting the JIT to work would be the > second. I am assuming native 32-bit binaries will run, just slower, so > this is an "optimization". :) I believe x86 BE is due for "sub-target" support to handle variations

Hi Markus, Thanks for this interesting patch! It looks okay to me, but our C/C++ Front End guru is away right now. I would rather defer to him on this patch. He might not get to it until next week so I just wanted to let you know that there might be a bit of a delay before this patch hits mainline. I've already committed your configure changes. Reid. On Wed, 2004-12-22 at 21:42, Markus

Markus F.X.J. Oberhumer wrote: > Hello folks, > > with the small patch attached below the whole llvm toolchain (llvm & llvm-gcc) > will compile and run under AMD64 Linux in native 64-bit LP64 mode. > > This means that compilation, bytecode management and CWriter output all work > as expected. Of course there is no JIT, and the bytecode interpreter is still > very

If by AMD64 you mean true 64-bit mode instruction set, I'd say it's different enough to warrant a new target. The differences between 386/486/586/etc are very minor in comparison. Reid Spencer wrote: >On Wed, 2004-12-22 at 22:40, Misha Brukman wrote: > > >>If you want to work on something, getting LLC to produce AMD64 code >>would be the first step, and getting

Aaron, On Thu, Jun 02, 2005 at 10:38:58PM +0100, Aaron Gray wrote: > http://www.st.cs.uni-sb.de/~lindig/src/quest/ I don't know about Tanu, but we can certainly use this in finding bugs in LLVM! This has been listed as an "open project" for a long time [1], but someone already implemented it, saving us the time and effort. Thanks for the link! [1]

On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer wrote: > While trying to hunt down a codegen bug (not yet found) ... Have you considered using bugpoint for your codegen debugging needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > I've collected some small patches you might find useful. Sweet! > Please review and apply as you see fit. I've

Dear LLVMers, If you live on the bleeding edge (i.e. CVS version), please read! On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Do you really want external patches for this ? A simple Perl script > that runs on all *.h and *.cpp files, and a local commit from your > side would be much simpler. I'm in the process of doing just this as we speak. What this

On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer > >wrote: Have you considered using bugpoint for your codegen debugging > >needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > > Well, the (critical) bug in question was >

On Fri, Apr 22, 2005 at 02:21:05AM +0200, Markus F.X.J. Oberhumer wrote: > Many thanks - attached you will find a list of files you still might > want to consider. Hmmm, those pesky .c and .in files, but I thought I covered all the .h and .cpp files... darn. OK, I'll trade you -- can you tell me how I can grep for a tab within a file? The following don't work for me: grep

On Fri, Apr 22, 2005 at 03:13:44AM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Fri, Apr 22, 2005 at 02:32:25AM +0200, Markus F.X.J. Oberhumer wrote: > >>[...] > >>bugpoint: Unknown command line argument '-instcombine-load-vn'. Try: > >>'bugpoint --help' > > > >You need a space between -instcombine and

On Wed, Nov 12, 2003 at 04:05:20PM -0800, Reid Spencer wrote: > On Wed, 2003-11-12 at 11:45, Vikram Adve wrote: > > > This implies that it is not intended for end-user consumption but > > > more for a proof-of-concept and ongoing research potential. > > > > You're being too modest, Misha --- this is going to be the Linux of > > the future :) > >

Let me add to one point that Misha made (just to show I actually read these messages!)... >> >> Any ballpark ideas on when an alpha version could be available? Are we >> talking months or years here? > > First of all, I would like to point out that the goal is *NOT* to > compile Linux > to run natively on your favorite architecture; instead, we aim to > compile

On Wed, Dec 22, 2004 at 11:01:37PM -0800, Jeff Cohen wrote: > Turns out it wasn't using the JIT. It was running the interpreter. The > X86 stuff wasn't being linked in. Alas, once I "fixed" that, it stopped > working. The JIT couldn't resolve the symbol "printf" and failed. But > the interpreter could resolve it. The interpreter has some hacks

On Wed, Apr 27, 2005 at 10:28:30PM +0200, Thomas Lodenscheidt wrote: > im dont understand. What is pr492? (url) http://llvm.cs.uiuc.edu/PR492 -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

Turns out it wasn't using the JIT. It was running the interpreter. The X86 stuff wasn't being linked in. Alas, once I "fixed" that, it stopped working. The JIT couldn't resolve the symbol "printf" and failed. But the interpreter could resolve it. Misha Brukman wrote: >On Wed, Dec 22, 2004 at 08:48:19PM -0800, Jeff Cohen wrote: > > >>I

Ms Brukman, Thanks for your reply.Just clarifying my question.I actually wanted to randomize the static layout of function code in the executable file.Sorry for writing in confusing manner. T Misha Brukman <brukman at cs.uiuc.edu> wrote: On Thu, Jun 02, 2005 at 02:12:22PM -0700, Tanu Sharma wrote: > By randomization of functions I mean the manner in whch they are > called , so

Constant *strcon==ConstantArray::get("Value : %d\n"); Sorry Typo. On Tue, 21 Dec 2004, Misha Brukman wrote: > On Tue, Dec 21, 2004 at 03:45:33PM -0700, Sriraman Tallam wrote: > > I have this call instruction to printf inserted which is causing > > an assertion failure. Any pointers to where I am wrong : > > > > Function

Sigh... take it up with Microsoft. On Fri, 24 Sep 2004 12:06:36 -0500 Misha Brukman <brukman at uiuc.edu> wrote: > On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > > (can't imagine it won't work). > > We prefer #include <cstdio>, since this is C++ after all. :) >

On Thu, Oct 07, 2004 at 06:46:18PM -0400, Shukang Zhou wrote: > Thanks Misha. I tried the "gcc -dM -E /tmp/file.c | grep __sparcv9" > but there was no output. Maybe this is the probelm, I do have > > CXX = g++ -mcpu=v9 > CC := gcc -mcpu=v9 > > in the Makefile.config. Do I need to add -m64 as well? Thanks. Just run the test that I mentioned before: > On Thu, 7

On Sat, Aug 21, 2004 at 04:15:49PM -0700, Jeff Cohen wrote: > I don't know if it's under cvs. It's the "getting started" page > (http://llvm.cs.uiuc.edu/docs/GettingStarted.html) in section "Getting > Started Quickly (A Summary)". But careful reading of the remainder of > the page does give the correct path. http://llvm.cs.uiuc.edu/docs/* is a copy of