LLVM and the current toolchain

Heimdall · Post by **Heimdall** » Thu Sep 11, 2008 7:24 pm

Hi guys,

Lately I've been interested on LLVM, it looks like a very promissing project and it could be nice to write a code emitter for the MIPS allegrex CPU for it. IMHO this would simplify the development since we can build the LLVM for any platform and just retarget our final ASM to the PSP CPU.

Anyone thinks this is a good idea or the current GCC and SDK is the way to go instead of writting LLVM bitcode and then cross compile to the PSP.

They claim that using their optimizer the generated assembly is (sometimes) better than the GCC one...

I just would like to hear some feedback from the forum on this!

hlide · Post by **hlide** » Thu Sep 11, 2008 9:43 pm

I was interested. But my experience with their old llvm-gcc 4.0 (LLVM 2.0) for iPhone shows me they still need to improve. I tried a PC cygwin version once but it generated a bad executable (i mean it wasn't right at computation) but it was a long time go.

Honestly, I was hoping for llvm, because it may be easier to add vfpu auto-vectorization.

The MIPS target contributer is normally considering a port for Allegrex (he posted once here for questions about FPU cycles) but i don't know about the real progress on it.

It's pretty hard for me to say if the new LLVM 2.2 is doing better for optimization as I didn't try it.

Anyway, if you are planning to do something for a psp port of llvm, you can count on me to help you.

hlide · Post by **hlide** » Thu Sep 11, 2008 9:47 pm

and clang may also be promising as a replacement of gcc too : http://clang.llvm.org/.

Heimdall · Post by **Heimdall** » Thu Sep 11, 2008 10:27 pm

Yes, clang looks promissing the only thing that worries me is that we need to compile all the SDK with it, i don't know if the gcc libs are compatible with llvm. What worries me there is the fact that we have some ASM specific code (all the .S files in the SDK) that I'm not sure how would llvm and clang handle...

hlide · Post by **hlide** » Fri Sep 12, 2008 12:02 am

so far, llvm-gcc produces :

1) direct 'as' sources
2) 'llvm' sources

if i'm not wrong llvm produces 'as' sources.

for the JIT, i dunno.

EDIT:

"The llvm-ld program has limited support for native code generation, when using the -native or -native-cbe options. Native code generation is performed by converting the linked bitcode into native assembly (.s) or C code and running the system compiler (typically gcc) on the result."

jean · Post by **jean** » Fri Sep 12, 2008 7:42 pm

....as far as i can see, Clang is very promising, but still severly limited "for the next two years" (as you can read on its site).... The idea to compile hi level code in low level bytecode for an ideal virtual machine surrounded by plenty of metadata and then give the ability to turn this into native code on release time is very smart. But this is all concerning only CPU....what about the remaining hardware of the platform? LLVM will not be able to automagically translate memory maps or device commands...I doubt this way one could mantain a single code for multiple platforms as PC/PSP without major differentiations usually handled with tons of "#ifdef"....
What do you think about it?

hlide · Post by **hlide** » Fri Sep 12, 2008 8:09 pm

but still severly limited "for the next two years"

that's for C++, C and Objective-C are already implemented even if they may be considered in alpha/beta stage.

LLVM will not be able to automagically translate memory maps or device commands

Nor does GCC ! and I'm not sure you look at LLVM : it is written in C++ and is largely modular and probably easier adaptable, customisable and maintenable unlike GCC. You can also have a JIT engine to generate Allegrex code in run-time, but I don't see it as the primary goal for a PSP port. I see it as an alternative to GCC.

Another interesting purpose :
http://lucille.lefora.com/2008/05/06/rs ... ted/page1/