similar to: [LLVMdev] binutils + gdb/insight targeted to LLVM

On Jul 17, 2008, at 7:51 PM, Richard Pennington wrote: > Hi, > > As part of my work with Elsa/LLVM I've been trying to wean myself from > gcc, I'm using my own preprocessor now (to eliminate gcc -E) and have > been calling ld and as directly. You should consider using the clang preprocessor :) > My question is: What assembler does the LLVM PIC target use? I'd

Chris Lattner wrote: > On Dec 22, 2007, at 2:40 AM, Richard Pennington wrote: > >> Does Elsa provide an advantage over g++? For me, understanding it is a >> big plus. ;-) In addition, Elsa has a Berkeley-like license which I >> prefer. > > Ok. If you're not planning on extending the front-end, > understandability doesn't really matter ;-). I get

Chris Lattner wrote: > On Dec 21, 2007, at 1:08 PM, Richard Pennington wrote: > >> I'm a little further along now. I've started to put together a simple >> driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think >> it works). >> >> The file being compiled is a "printf" function. Here are timing >> results

On Dec 22, 2007, at 2:40 AM, Richard Pennington wrote: > Does Elsa provide an advantage over g++? For me, understanding it is a > big plus. ;-) In addition, Elsa has a Berkeley-like license which I > prefer. Ok. If you're not planning on extending the front-end, understandability doesn't really matter ;-). I get where you're coming from though! > Since I only

Daniel Wilkerson wrote: >> I've build gcc many times over the years for different target processors >> and was never able to get my head around it internally. It is incredibly >> complex. I also didn't like the fact that I had to have N copies of gcc >> to support N processors. > > Scott McPeak is rather familiar with the internals of gcc and edg and >

Eli Friedman wrote: > I haven't looked at the rest of the email carefully, but why aren't > you just implementing MULHU and MULHS? There's no point to > implementing the *MUL_LOHI variants if the processor doesn't have > them. I have implemented MULHU and MULHS. But if I take out my *MUL_LOHI stuff, the error I get is [~/ellcc/ellcc] main% ./nios2-elf-ecc -S test.c

Richard Pennington wrote: > Eli Friedman wrote: > >> I haven't looked at the rest of the email carefully, but why aren't >> you just implementing MULHU and MULHS? There's no point to >> implementing the *MUL_LOHI variants if the processor doesn't have >> them. >> > > I have implemented MULHU and MULHS. But if I take out my

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);

I'm a little further along now. I've started to put together a simple driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think it works). The file being compiled is a "printf" function. Here are timing results for optimized and unoptimized runs: [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions Adding test/ofmt.i as a preprocessed C file

On Dec 21, 2007, at 1:08 PM, Richard Pennington wrote: > I'm a little further along now. I've started to put together a simple > driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think > it works). > > The file being compiled is a "printf" function. Here are timing > results > for optimized and unoptimized runs: Cool, this is

> I've build gcc many times over the years for different target processors > and was never able to get my head around it internally. It is incredibly > complex. I also didn't like the fact that I had to have N copies of gcc > to support N processors. Scott McPeak is rather familiar with the internals of gcc and edg and says elsa is far simpler. > I became interested in

ELLCC is a compilation tool chain based on clang/LLVM, libc++ and the musl standard C library for Linux. Recently I was asked if ELLCC pre-built binaries could be used to build clang/LLVM TOT. It turns out that it can with some simple patches. This is a simple way to bootstrap clang/LLVM on an arbitrary Linux system that either doesn't have GCC or has a version of GCC that is too old to

Hi, I have completed enough of the Nios2 code generator that I think it is appropriate to bring it into the source tree. What is the best approach to take? It all sits in one directory, of course: lib/Targets/Nios2. Besides that directory, the only other change I've made is to configure. The code generator is complete, but requires more testing. How should I proceed? Should I commit

On 12/21/07, Richard Pennington <rich at pennware.com> wrote: > I'm a little further along now. I've started to put together a simple > driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think > it works). Er. Hm. Can you explain the name? The problem with names like "ellsif" is that it sounds like "else if". I like the

A while back (2012) there were a few messages related to using YAML config files to set up how clang would build stuff, especially for cross compilers. My ELLCC project is entirely cross compilation focused, so today I decided to play around with the config file idea. Right now it only handles replacing a "-target foo" option with the options defined in the file foo in the

(Fixed the cfe email address) On 12/18/2015 09:34 PM, Tim Northover wrote: > On 18 December 2015 at 19:15, Richard Pennington via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It turns out that it can with some simple patches. > This sounds really cool. I think we should seriously consider putting > these patches into LLVM mainline. > >> Information on

I've been working on adding code coverage support to my ELLCC project (http://ellcc.org) and I thought it would be nice to fun the index page of the HTML output of llvm-cov into something a little prettier and more useful. The initial result is here: http://ellcc.org/coverage/ If there is any interest, I'll submit the llvm-cov changes. -Rich

[~/ellcc/test/source] main% cat printf.c #include <stdio.h> int main(int argc, char** argv) { printf("printf with the string \"%s\"\n", "my string"); } [~/ellcc/test/source] main% ~/ellcc/ellcc/x86-elf-ecc printf.c [~/ellcc/test/source] main% ./a.out printf with the string "my string" [~/ellcc/test/source] main% size a.out text data bss

Hi, I asked this question a few days ago and didn't get any responses. I thought I'd try again with a little more detail. I am trying to cross compile my clang/LLVM based ELLCC cross development tools project (http://ellcc.org) on a Mac. I am targeting ARM/Linux. The build fails while building FileCheck (or tbl-gen or any of the other build tools built during the

Hi, I recently switched over to using cmake to build my clang/LLVM based ELLCC cross development project (http://ellcc.org). I also recently updated to LLVM svn version 258915 from 258477. I use ELLCC to cross compile all the tools for various Linux targets and for Windows. Yesterday, after updating the LLVM sources, I got the following error when cross building for MinGW: [ 3%] Built