similar to: [LLVMdev] Any idea on translate x86 assembly to LLVM IR?

I'am now considering converting x86 machine assembly into LLVM IR, does anyone know about any existing project or resource related to this area? Any difficulities or any ideas on this? thanks for your replies in advance. cradnil 2008-03-04 -------------- next part -------------- An HTML attachment was scrubbed... URL:

Tilmann Scheller <tilmann.scheller at googlemail.com> writes: [snip] > It might be worth to put an Eclipse CDT project file with relative > paths to the header files in the LLVM SVN repository to make it easier > for people to use Eclipse in the future (my project files currently > contain absolute paths, so they're probably not useful to other > people). CMake can

Thanks for all the replies! I wanted to closely resemble what the CACAO VM[1] backend did with success for a long time: for every CACAO IR instruction, there is a sequence of x86 instructions that get written directly to the executable memory. In CACAO, registers are used while available, then everything is spilled. Relocations are resolved and patched in a second go. It seems this is similar to

Tilmann Scheller <tilmann.scheller at googlemail.com> writes: > Apparently CMake deletes the C++ files which are generated by > TableGen, is it possible to tell CMake to not throw them away? Certainly the build does not delete those files. Maybe you looked at the wrong place. Try $OBJDIR/lib/Target/X86, for instance. There you will see the *.inc files that TableGen creates. >

On Jul 17, 2013, at 1:19 PM, Tilmann Scheller <tscheller at apple.com> wrote: > I actually never did a build with Eclipse, only used it for code navigation and debugging :) Actually that’s not really true, I did build with Eclipse from time to time to get all the sources TableGen generates automatically. This is really nice because the source navigation works just fine across handwritten

On Tue, Apr 1, 2008 at 9:49 AM, Vania Joloboff <vania at liama.ia.ac.cn> wrote: Hello, > > We are a research project in joint french-chinese laboratory. We are > considering using > LLVM in our project but we'd like to have some additional info before we > dive in. > Since we are new kids on the block, please bear with us... > > We are interested in using LLVM

On 07/16/2013 05:21 AM, Tilmann Scheller wrote: > Hi Reed, > > I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years). > > Xcode works fine as well, I started to use Xcode

On 07/16/2013 05:21 AM, Tilmann Scheller wrote: > Hi Reed, > > I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years). > > Xcode works fine as well, I started to use Xcode

instcombine doesn't seem to be doing it. From my testing it seems to only occur when I use -indvars after a long string of commands. For example: llvm-as < test_fc_27.ll | opt -preverify -domtree -verify -lowersetjmp -raiseallocs -simplifycfg -domtree -domfrontier -mem2reg -globalopt -globaldce -ipconstprop -deadargelim -instcombine -simplifycfg -ba siccg -prune-eh -inline

Hi, Tilmann Scheller wrote: > On Wed, Jun 10, 2009 at 3:03 PM, Andreas > Neustifter<e0325716 at student.tuwien.ac.at> wrote: >> Is there something wrong with my cross-compiler or is the llc-generated code bad? > Most likely the latter, the powerpc64-unknown-linux-gnu target is not > officially supported by LLVM. In fact there is no support for the > 64-bit PowerPC

Hi, I am using Eclipse to edit the files, and I used it to debug with gdb as well (but I went back to gdb on the command line, Eclipse GDB UI is just too slow and buggy for me ..). You need to exclude the clang preprocessor/.. stress tests from the sources, otherwise the indexer will freeze Eclipse. You should also remove some autogenerated CMake project subdirectories, otherwise your files

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Thanks to all those who responded to our email.<br> <br> Tilmann Scheller wrote: <blockquote

On 25/09/09 18:05, Tilmann Scheller wrote: > Hi Andrew, > > On Wed, Sep 23, 2009 at 7:26 AM, Andrew Jeffery<andrew at aj.id.au> wrote: >> TCG seperates the guest (ARM) code into blocks - my front end translates >> these to LLVM IR for LLVM to translate to x86. The assumption is that LLVM >> will produce a better translation than TCG*. At some future point the

Hi Tilmman, Thanks for submitting this. Here's some feedback. On Sun, 2007-03-25 at 00:41 +0100, Tilmann Scheller wrote: > Hello, > > here's my proposal for a GSoC project with LLVM. I'm happy for any > feedback or advice you can give me. > > Thanks in Advance > > Tilmann > > > * Proposal for Google Summer of Code Project > > ** Using

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Tilmann Scheller wrote: <blockquote

Hi Patrick, On Thu, Jul 2, 2009 at 12:17 AM, Patrick Alexander Simmons<simmon12 at cs.uiuc.edu> wrote: > Has anyone tried using the Eclipse CDT plugin (or another C++ IDE) to > develop code in LLVM? I'm specifically interested in getting code > completion to work. I've been sucessfully using the Eclipse CDT with LLVM for quite a while now. The official releases of Eclipse

Hi Oscar, On Thu, Jul 2, 2009 at 2:59 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> It might be worth to put an Eclipse CDT project file with relative >> paths to the header files in the LLVM SVN repository to make it easier >> for people to use Eclipse in the future (my project files currently >> contain absolute paths, so they're probably not useful to other

On Fri, Mar 4, 2016 at 11:28 AM, Tilmann Scheller <tilmann at osg.samsung.com> wrote: > Hi Sedat, > > On 03/03/2016 08:09 AM, Sedat Dilek via llvm-dev wrote: >> >> It might be that a CLANG generated with LTO/PGO speeds up the build. >> Can you confirm this? > > Yes, a Clang host compiler built with LTO or PGO is generally faster than an > -O3 build. >

Hi Viktor, On Tue, Apr 5, 2011 at 9:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Jim Grosbach <grosbach at apple.com> writes: > > >> To me, increasing coverage of the FastISel seemed more involved than > >> directly emitting opcodes to memory, with a lesser outlook on > >> reducing overhead. > > > > That seems extremely unlikely.

Hi Andrew, On Wed, Sep 23, 2009 at 7:26 AM, Andrew Jeffery <andrew at aj.id.au> wrote: > TCG seperates the guest (ARM) code into blocks - my front end translates > these to LLVM IR for LLVM to translate to x86.  The assumption is that LLVM > will produce a better translation than TCG*. At some future point the > TCG-generated native block is replaced by the LLVM's, and as