Differences between open64 and llvm compilers

Question

Can someone point out the differences between open64 and llvm?

I know that open64 uses a whirl IR, which has 5 stages and is very different, since each stage significantly reduces the code for the machine, while llvm has one IR, which is used in mid-level optimization, then it is dropped into target independent commands (dags) and dependent.

1) Is the vortex also an SSA,
2) , and it uses virtual registers,
3) . open64 has a modular design such as llvm,
4) Is it easy to design a passage and connect it to the tool chain?

Both compilers outperform average inter-procedure optimizations and transforms, but
5) Does open64 have JITting support or any kind of dynamic translation built into the structure?

It seems that the quality of the CG is more or less the same in both cases.
6) What about fronts, is it possible to easily expand them using pragmas or to connect new ones without changing Whirl IR (is this a problem with SUIF)?

As far as I can tell, open64 is widely used in many commercial and academic projects (UPC, AMD, Nvidia, Tensilica), but it seems that there are many of its branches (growing after 2003), and each has its own functions and limitations. Moreover, there is no developer community and environment or developer support, documentation is unlikely to exist unlike llvm, and there is simply no easy direction in which the compiler is moving.

There are also differences in licensing, when llvm is more in line with the BSD licensing style, and open64 is based on the GPL.

Answer 1

Q: Whirlwind is also SSA A: No, but Open64 has SSA Manager A: No, but Path64 will either take the SSA Manager approach or convert all optimizations to SSA this year.

Q: Does it use virtual registers A: In Path64 / Open64 you do not perform the final allocation of registers until the cg phase

Q: Does it have a modular design, for example, llvm A: (Given the opinion, and I am biased). Each phase is purely separated, so it is somewhat modular, but not to the same extent that you will find in llvm. Please note that I doubt that at this point you can disable some things in llvm without significant consequences. Thus, isolating testing one type of optimization may / may not be easier from the point of view of the researcher.

Q: Is it easy to design a passage and connect it to the tool chain? A: Yes / no - LLVM wins the docs, but Path64 is working on it. Some code is easier to jump than others. If you are completely fresh for compilers, then use LLVM to work with the interface or with the source code. If you have experience and want to develop a more advanced path64 git: //github.com/path64/compiler.git optimization, then I would recommend.

Q: Does open64 support JITting? A: No, but why do you need it? Path64 is the strongest during static compilation and spends 200 thousand cycles per JIT, which some bytecode rarely makes sense.

Q: What about fronts? A: clang will be the default in llvm-2.10, but before that they both use the gcc interface. There is a non-public project that allows the use of WHITL. This again places them on a flat surface.

Minor corrections - LLVM IR is more comparable with CG IR and not quite WHIRL mid-level. It seems that the quality of the CG is more or less the same in both cases. I would say that this is an absolutely false assumption, and I will not comment on which is better, but I will say that they differ significantly

In addition, there is no specific developer community or environment or support.

#pathscale - irc.freenode.net (we also have mailing lists and your questions will be received)

Internally, many companies have good documentation, but usually they are not provided and are not available as needed. (I am codestr0m on irc and probably can share our success)

in one direction the compiler is moving.

There is one direction for us, and we are trying to create a community around it.

There are also differences in licensing, when llvm is more in line with the BSD licensing style, and open64 is based on the GPL.

Sorry, but I'm not a lawyer and don't care about licensing until it bothers me.