Differences between open64 versus llvm compilers

Could someone point out the differences between the open64 and llvm?

I know that the open64 uses whirl IR which has 5 stages and differs a lot since each stage lowers significantly the code to the machine whereas the llvm has a single IR which is used in midlevel optimizations, later is lowered into target independent instructions (dags) and dependent ones.

1) Is whirl also SSA,

2) and does it uses virtual registers,

3) does open64 has modular design like llvm,

4) is it easy to develop pass and plug it into the toolchain?

Both compilers excel at midlevel i开发者_JAVA百科nterprocedural optimizations and transformations but

5) does open64 have support for JITting or any kinds of dynamic translation natively built into the framework?

It looks that the quality of CG more or less is similar in both cases.

6) What about the front ends, is it possible to easily extend ones with pragmas or bind new ones without modifying the Whirl IR (that is the problem with SUIF)?

As far as I can tell the open64 is widely used in many commercial and academical projects (UPC, AMD, Nvidia, Tensilica) but it looks that there are many branches of it (growing after 2003) and each has it's own features and limitations. Moreover, there isn't fixed developer community and environment or support, the documentation hardly exists in contrast to the llvm, and simply there isn't simple one direction in which the compiler advances.

There are also differences in licensing where the llvm matches more to BSD licensing style and the open64 is based on GPL.

Q: Is whirl also SSA A: No, but Open64 has SSA Manager A: No, but Path64 will either adopt the SSA Manager approach or convert all optimizations to be SSA aware this year

Q: Does it uses virtual registers A: In Path64/Open64 you don't do final register allocation until the cg phase

Q: Does it have modular design like llvm A: (Subject to opinion and I'm biased) Each phase is cleanly divided so it's somewhat modular, but not to the same extent you'd find in llvm. Please note that I doubt at this point you could turn off certain things in llvm without a lot of repercussions. So the isolation of testing a single type of optimization may/may not be easier from a researcher perspective.

Q: Is it easy to develop pass and plug it into the toolchain? A: Yes/no - LLVM wins hands down on documentation, but Path64 is working on that. Some code is easier to jump into than others. If you're totally fresh to compilers, doing front-end work or source-to-source go with LLVM. If you have experience and want to develop a more advanced optimization Path64 git://github.com/path64/compiler.git is what I'd recommend.

Q: Does open64 have support for JITting? A: No, but why would you want it? Path64 is strongest at static compilation and spending 200k cycles to JIT some byte-code rarely makes sense.

Q: What about the front ends? A: clang will be the default in llvm-2.10, but before that they both use the gcc front-end. There is a non-public project to take clang an emit WHIRL. This puts them both on even ground again.

Small corrections - LLVM IR is more comparable to CG IR and not really a mid level WHIRL. It looks that the quality of CG more or less is similar in both cases. I'd say this is a totally false assumption and I won't comment on which is better, but will say they are substantially different

Moreover, there isn't fixed developer community and environment or support

#pathscale - irc.freenode.net (We also have mailing lists and your questions will get answered)

Internally many companies have good documentation, but it's usually not shared or available on an as-needed basis. (I'm codestr0m on irc and can likely share the progress we've made on this)

one direction in which the compiler advances.

For us there is one direction and we're trying to build a community around it.

There are also differences in licensing where the llvm matches more to BSD licensing style and the open64 is based on GPL.

Sorry, but I'm not a lawyer and don't care about licensing as long as it doesn't get in my way..