similar to: [LLVMdev] Re: LLVM to SUIF-MACH VM binary

Chris Lattner wrote: > On Tue, 18 Jan 2005, John Cortes wrote: > >> Hi Chris, > > > Hi! I'm CC'ing the llvmdev list for the benefit of others. > >> Since I see you're very involved in LLVM, I need a little guidance on >> getting from C to MACH-SUIF. >> >> I've been given the task of using LLVM to translate C code to another

A couple notes on this: 1. We also need to be able to *read* .o files for linking. Right now we just assume that any symbol not found in a bytcode file is implemented in some native library and will be resolved at runtime. This isn't the greatest assumption. To resolve native binary symbols we need to be able to read native .a, .so, and .o files to ensure the symbols are

On Tue, 18 Jan 2005, John Cortes wrote: >> Can you say a little bit about MACH-SUIF? With a brief google search, I >> didn't turn up anything that described the architecture. Is it a RISC-like >> machine with 32-bit instruction words? >> > > It's another VM representation. I haven't really gotten to know the nitty > gritty of the language so

On Thu, Jan 20, 2005 at 02:38:39AM -0800, John Cortes wrote: > I tried including the SUIFvm header files and got more errors than I > bargained for. Looks like it hasn't been updated to be portable. I > need some help in getting these suifvm references into the code I'm > writing. While I understand that your current goal is translating LLVM -> SUIF, it seems that

Chris Lattner wrote: > On Tue, 18 Jan 2005, John Cortes wrote: > >>> Can you say a little bit about MACH-SUIF? With a brief google >>> search, I didn't turn up anything that described the architecture. >>> Is it a RISC-like machine with 32-bit instruction words? >>> >> >> It's another VM representation. I haven't really gotten

Nikolaos Kavvadias wrote: > Dear friends, > > I have been using the SUIF Machine infrastructure for sometime. Some > optimizations are available without using a target machine, i.e. at the > SUIFvm level. At this level you have "infinite" registers. Other > optimizations, including analyses as for profiling require the use of a > target library, a complete

Dear friends, I have been using the SUIF Machine infrastructure for sometime. Some optimizations are available without using a target machine, i.e. at the SUIFvm level. At this level you have "infinite" registers. Other optimizations, including analyses as for profiling require the use of a target library, a complete backend. It is very sad, that they have discontinued their MIPS

--- David Greene <greened at obbligato.org> wrote: > Roman Levenstein wrote: > > The allocator does not handle register aliases and register classes > > correctly, which makes it rather unusable for most architectures. > One > > idea that can be used for improving handling of irregular > architectures > > is described in the "A Generalized Algorithm for

Roman Levenstein wrote: > Yes, the SUIF allocator (or at least one of them) implements the > Smith/Ramsey/Holloway algorithm. This is what I understand by looking > at the coloring reggister allocator code in the SUIF distribution. The > SUIF code of this allocator is not very well commented, but I'm pretty > sure. Do you have a pointer? I'm interested in this algorithm

Roman Levenstein wrote: > The allocator does not handle register aliases and register classes > correctly, which makes it rather unusable for most architectures. One > idea that can be used for improving handling of irregular architectures > is described in the "A Generalized Algorithm for Graph-Coloring > Register Allocation" by Michael D. Smith, Norman Ramsey and Glenn

i don't know the status of nci, but suif/suif2 development and publication is very active. it's will be great if there are tools to transform llvm ir and suif ir to each other. acutally, i didn't use suif but llvm just because suif cannot be compiled by visual studio.net (but visual studio 6). On 5/10/05, Vladimir Prus <ghost at cs.msu.su> wrote: > On Tuesday 10 May 2005

Hi, --- Anton Vayvod <avayvod at gmail.com> wrote: > On 4/3/07, David Greene <greened at obbligato.org> wrote: > > > > I'm just starting to dive into llvm, hoping to implement a > > good graph coloring register allocator. I gather that this > > has been discussed before. > > > > What is the RegAllocGraphColoring.cpp currently in the >

Hi Dave, --- David Greene <greened at obbligato.org> wrote: > Roman Levenstein wrote: > > > Yes, the SUIF allocator (or at least one of them) implements the > > Smith/Ramsey/Holloway algorithm. This is what I understand by > looking > > at the coloring reggister allocator code in the SUIF distribution. > The > > SUIF code of this allocator is not very

Hey everyone! Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool. Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O

Thanks for the response, Rui! On Tue, Jun 5, 2018 at 5:26 PM, Rui Ueyama <ruiu at google.com> wrote: > > Besides the features you pointed out, I think Xcode introduced a new way > of listing dynamic linking symbols, and I believe lld doesn't support that. > .tbd files, is that right? A colleague of mine pointed me to Apple's libtapi open source project [1], maybe I can

I'd be interested in the existence of a high-quality, open-source, portable linker for apple platforms, but not enough to help make that happen. If I _was_ gonna work on something related to that, I'd probably be inclined to instead add any required features to allow an ELF linker to target a notional darwin-elf target, and to have clang emit darwin-elf object files, and then write a

On 2020-02-28, James Y Knight via llvm-dev wrote: >Nice! > >Your plan sounds great, and it'll be awesome to finally have a good MachO >LLD available. > >On Fri, Feb 28, 2020 at 4:32 PM Shoaib Meenai via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> We’re planning to contribute a new implementation of LLD for Mach-O, using

Hello all, I'm trying to better understand the state of Mach-O support in lld. The lld docs state that "the linker supports ELF (Unix), PE/COFF (Windows), Mach-O (macOS) and WebAssembly in descending order of completeness." [1] True to that statement, I found an email on this list from Jan 2018 stating that "MachO support in lld is not really ready for real world usage. It was

We're in the process of importing lld into FreeBSD (along with our Clang 3.9 update project). For now I've removed all but the ELF linker[1]. We have no need for COFF and Mach-O, and we have a bespoke build system for all of our contrib code. I didn't bother adding build support for the source files for non-ELF linkers. Is this something that'd be reasonable / desirable to have

Hello, I'm finally getting back to getting JIT debugging work for MCJIT. This has worked for ELF for a while in LLVM and support in lldb was added in January (for ELF). I'm now trying to add support for Mach-O and would appreciate some feedback (though I'm fighting my way through learning the format, I'm still just a novice). My current patchset for llvm is here: