similar to: [fwd] Re: [LLVMdev] Hash Bang

On Sat, 1 Oct 2005, Misha Brukman wrote: > Karl, I think you meant to cc the llvmdev list on this. > > Thank you for a more detailed explanation, it's much clearer to me now. That does make more sense to me too. > I agree that making the execution of .bc files more transparent would > make it more useable as a stand-alone binary format on Unix-like systems > and adding

Currently, llvm bytecode files must begin with llvm\d where \d = {0,1,2}. Have you considered allowing a "hash bang path" to precede the llvm magic number? This would allow llvm modules to be executable on UNIX systems (and under cygwin). Would the community find this useful? I like the idea of platform-independent binaries being able to masquerade as native executibles. I'm

On Thu, Oct 07, 2004 at 06:22:34PM -0400, Shukang Zhou wrote: > I am working with llvm 1.3 on a sparcv9 machine. I have successfully > built llvm and llvm-gcc frontend. I can run many tools including > llvmgcc, llvm-dis, and llc. After using /opt/SUNWspro/bin/cc to > assemble .s file into a program binary, I can run the binary correctly > as well. > > I am interested in the

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

Hey, Jakob -- On Tue, Mar 01, 2005 at 05:55:07PM +0100, Jakob Praher wrote: > I'm really new to llvm. I've successfully bootstrapped llvm-14 on my > system and am able to successfully compile c code to llvm. > > the problem is now that gccld is complaining that it can't find the > libraries, like "c" or "crtend". [1] Did you install the bytecode

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

> >>> Would be great if we append into the documentation several "patters" > >>> to show how perform with LLVM. It would accelerate the learn curve for > >>> beginners like me, avoiding basic errors and mistakes. If I reach a > >>> good level with LLVM I can make these. > >> > >> I'm not sure if I understand what you

Thanks for your valuable input. By the way, I am exporting CC=llvm-gcc and RANLIB=llvm-ranlib for projects that use it. It was a mistake not to write it in the post as apache indeed uses gcc. If you see the error message, you would see llvm-gcc being used. I would try to investigate further on the lines you have mentioned. However, the question that stands is how to best handle failure to compile

On Wed, Aug 04, 2004 at 08:19:58AM -0700, Reid Spencer wrote: > How about something along the notion of "build or construct" as in we > have two primary tools in llvm: > > llvm-build - builds programs to be run llvm-build or llvm-driver are both kinda long but at least they make sense... As an aside, llava and llama are both taken, llvmize? llvminator? llvm-emerge a la

I'm sorry, I did not completely understand your email, let me clarify my response. 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

On Wed, Dec 22, 2004 at 08:48:19PM -0800, Jeff Cohen wrote: > I compiled a simple "hello world!" C program on FreeBSD, transfered > the a.out.bc file to Windows, and executed it with an lli.exe that I > built with Visual Studio. It worked! Great news, but note that not all bytecode files are so portable. :) -- Misha Brukman :: http://misha.brukman.net ::

Really JIT isn't my goal. I prefer use a native execution engine; and ok, I don't need save the generated Module so it ever lives in memory, so if LLVM doesn't generate relocatable code it's fine for me. About the reentrant lacks of LLVM, I can convert my own code - which build the Module - into a critical section so I think it is enough; but I need to know if several independent

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. Shukang On Thu, 7 Oct 2004, Misha Brukman wrote: > Is your compiler configured to define __sparcv9 when it compiles? > The following should tell

On Wed, Jan 21, 2004 at 08:25:23AM -0800, Robert Mykland wrote: > I'm the guy who is working on the LLVM bytecode documentation. The > document I have at present just supports the bytecodes my code > generator processes, though, which is far from all of them. As I get > farther along with my code generator I expect I'll get to the point > where everything kind of fits

Yeah. We need to have more extra fields in the instruction. Fo example, during high-level synthesis, we must schedule an instruction to a certain control step (or cycle), and bind it to be execute on a certain functional unit, etc. Besides the in-memory exchange of the information, we also want on-disk exchange. That introduces the write-out/parse-in problem. Thanks ----- Original Message -----

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

On Fri, Dec 31, 2004 at 02:30:00PM +0100, Francisco Puentes wrote: > Now I have other problem: I have a Module and I need generate a > iostream (memory) with native x86 code (maybe elf/coff) to be executed > later (into the guest process space, without fork!!). I studied llc > and lli, but they don't help me much. Any idea? Are there any guy > working in some like that? In

On Sat, Jan 08, 2005 at 06:16:47PM +0100, Francisco Puentes wrote: > I have points 0-4 working, but I am confused about point 5 and maybe 6. [snip and reorder] > (5) Generate native (x86) code from generated module The JIT currently is built to generate native code for a given module, a function-at-a-time. That means that first, main() is generated, and anything main() calls is not. As

On Fri, Apr 08, 2005 at 08:37:03AM -0700, Tanu Sharma wrote: > Regarding basic block size I wish to calculate both: > > - The number of bytecode bytes Use the llvm-bcanalyzer tool, it will tell you number of bytes per function and number of basic blocks. If you want number of bytes per basic block, check out what it does, and calculate basic blocks separately. > - The number of

On Wed, 2004-08-04 at 08:51, Misha Brukman wrote: > llvm-build or llvm-driver are both kinda long but at least they make > sense... Yeah, that's my sense too. > > As an aside, llava and llama are both taken, llvmize? llvminator? > llvm-emerge a la gentoo? Uh. No? > > > llvm-run - runs programs built by llvm-build > > Wait, is llvm-run the same as lli?