llvm dev - Nov 2006 - [LLVMdev] LLVM Newb: Getting started

A few days ago Craig Black made the suggestion in the D newsgroup, 
that someone creates a D <http://www.digitalmars.com/d/index.html> 
frontend for LLVM. Never having heard of LLVM in the past, I 
immediately got captured by its design when I've read the 
documentation. I was always scared by GCC - a great piece of 
software, but horribly bad documented, and in it's own way not very 
KISS.

Since I'm currently working on a clean ABI draft for D I thought, that 
implementing a D frontend for LLVM would also be a good test case for 
my ABI drafts and so I agreed to implement that frontend.

Today I've built LLVM from source (however not the GCC frontend yet) 
and played a bit with the assembly language, and it brought up the 
following questions:

* How can I define parts of the ABI that cover calling conventions?

* Which is the LLVM way of creating object files?
From what I've tried out yet, the llvm-ld will generate a executable. 
llc produces target specific assembly; there is an option to output 
object files, but this crashes on my system.

* Which is the best way to add support for new object file types. One 
thing that a lot of people in the D community anticipate is the 
possibility to compile modules into self contained objects, which can 
be redistributed without additional header files, and be linked 
either statically or dynamically into the final program. Kinda like 
Pascal units. This of course requires to put additional information 
into the created binary. And I'd like to try, to let the thing to 
create CLI binaries 
<http://www.ecma-international.org/publications/standards/Ecma-335.htm>.

And last but not least: Which parts of the documentation must I 
definitely read in the first place to get started to hack LLVM (I'll 
read all of course, but I'd like to focus right now).

-- 
Wolfgang Draxinger
lead programmer - DARKSTARgames

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20061123/81e21638/attachment.sig>

Hi Wolfgang,

On Thu, 2006-11-23 at 19:47 +0100, Wolfgang Draxinger
wrote:
> A few days ago Craig Black made the suggestion in the D newsgroup, 
> that someone creates a D <http://www.digitalmars.com/d/index.html> 
> frontend for LLVM. Never having heard of LLVM in the past, I 
> immediately got captured by its design when I've read the 
> documentation. I was always scared by GCC - a great piece of 
> software, but horribly bad documented, and in it's own way not very 
> KISS.
Welcome to LLVM :)
> Since I'm currently working on a clean ABI draft for D I thought, that 
> implementing a D frontend for LLVM would also be a good test case for 
> my ABI drafts and so I agreed to implement that frontend.
Wonderful!
> Today I've built LLVM from source (however not the GCC frontend yet) 
If you're making your own front end, you probably won't need it :)
> and played a bit with the assembly language, and it brought up the 
> following questions:
> 
> * How can I define parts of the ABI that cover calling conventions?
LLVM supports calling conventions, if that's what you mean. You can even
create your own, but you'd have to implement them in the code
generators.
> 
> * Which is the LLVM way of creating object files?
> From what I've tried out yet, the llvm-ld will generate a executable. 
> llc produces target specific assembly; there is an option to output 
> object files, but this crashes on my system.
llvm-ld should generate an executable, but alas it is an unfinished
piece of work. 
generally what we do is:

llc input.bc -o output.s
gcc output.s -o program

I've been meaning to finish the llvm-ld and llvmc tools for some time
now but other things have consistently gotten in the way.  One of these
days they'll be working.

Note that you should be able to write a "D" configure file for llvmc
that sets up the various stages for compilation of D programs through
linking. Unfortunately, there isn't much good documentation on it and
the file format is not good. There's an open bug to clean this all up,
but it is not, as yet, implemented.
> * Which is the best way to add support for new object file types. One 
> thing that a lot of people in the D community anticipate is the 
> possibility to compile modules into self contained objects, which can 
> be redistributed without additional header files, and be linked 
> either statically or dynamically into the final program. Kinda like 
> Pascal units. This of course requires to put additional information 
> into the created binary.
If you can create platform independent code from D, then you should be
able to just use the LLVM bytecode representation. Most of the tools put
this format out. Note that LLVM bytecode files are only as platform
independent as the language front end used to create them. The bytecode
files can be distributed and then targeted to any of the platforms that
LLVM supports. The bytecode format even retains which libraries it still
needs to link against so you should be able to turn the bytecode into an
executable fairly readily.
>  And I'd like to try, to let the thing to 
> create CLI binaries 
>
<http://www.ecma-international.org/publications/standards/Ecma-335.htm>.
Sounds interesting. How much like Microsoft CLR is it? You could
probably create a backend for CLI quite readily. See the "C" Backend
that turns LLVM IR into C99 code. You can see it here:
http://llvm.org/cvsweb/cvsweb.cgi/llvm/lib/Target/CBackend/Writer.cpp?rev=1.282&content-type=text/x-cvsweb-markup

Writing a backend to support CLI output should be on the same order of
magnitude as that file. Its not particularly difficult due to the
regularity/simplicity of the LLVM IR.
> 
> And last but not least: Which parts of the documentation must I 
> definitely read in the first place to get started to hack LLVM (I'll 
> read all of course, but I'd like to focus right now).
Try this:

http://llvm.org/pubs/2006-04-25-GelatoLLVMIntro.html 
http://llvm.org/docs/GettingStarted.html 
http://llvm.org/docs/LangRef.html 
http://llvm.org/docs/CommandGuide/index.html 
http://llvm.org/docs/ProgrammersManual.html 
http://llvm.org/docs/GetElementPtr.html 
http://llvm.org/docs/FAQ.html 

Reid.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Am Freitag, 24. November 2006 03:00 schrieb Reid Spencer:
> If you're making your own front end, you probably won't need it :)
Well, I wanted to play around with it, so see, how my older programs 
perform with it.

So far I managed to get some programs running by folowing scheme:

for src in $infiles; do
llvm-gcc -o $src.bc -c $src ;
opt -f -o $src.bc.opt $src.bc ;
llc -f $src.bc.opt ;
gcc -c $src.bc.opt.s ;
done

gcc -o $name *.o

However until now I always had to compile the source file with the 
main function directly with gcc, so that the __main function (to 
initialize the globals and static constructors) gets created. 

I did not manage to make llvm-gcc create __main.
> If you can create platform independent code from D, then you should
> be able to just use the LLVM bytecode representation.
D itself is platform independent, but since D is also aimed at system 
programming it has an inline asembler. However one can supply 
different kinds of assembler through conditional comilation, so the 
following would be completely valid:

void foo(){
    version(x86) {
        asm {
/* x86 assembler */
        }
    } else version(llvm) {
        asm {
/* llvm assembler */
        }
    } else {
/* plain D implementation */
    }
}

<http://www.digitalmars.com/d/iasm.html>
<http://www.digitalmars.com/d/version.html>

Any ideas, how this could be integrated with LLVM? The IMHO most naive 
approach would be to add labels where the asm begins and ends. Then 
the plattform dependent assembler being parted from the code llvm 
gets to see and being processed by an external assembler into object 
code. Later in the process the linker then reinserts the assembler 
object code.

-- 
Wolfgang Draxinger
lead programmer - DARKSTARgames

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20061125/23841fdc/attachment.sig>

Hello, Wolfgang.
> I did not manage to make llvm-gcc create __main.
Code for static construction & destruction is highly platform dependent.
Usually it's placed in crt.o binary, which is compiled during main gcc
build cycle.

For example, for Linux we should only output some code in specialy named
sections and this code will automatically called by system loader. As
opposite, for mingw32 we're emitting "__main" directly.

You can change default behaviour by changing
X86DAGToDAGISel::EmitSpecialCodeForMain() routine located in the
lib/Target/X86/X86ISelDAGToDAG.cpp file (I'm assuming, you're using some
x86 target). 

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.