RTL <-> SSA

Hi,

Does LLVM have passes that do translations between GCC RTL and LLVM
SSA, RTL -> SSA and SSA -> RTL?

Thanks.

Nope. There has been some talk about doing a Clang -> RTL or LLVM IR -> RTL backend, to allow using the GCC backend with the Clang frontend, but I'm not aware of any progress on this. You could ask on the gcc mailing list about it.

-Chris

Hi,

Does LLVM have passes that do translations between GCC RTL and LLVM
SSA, RTL -> SSA and SSA -> RTL?

Nope. There has been some talk about doing a Clang -> RTL or LLVM IR -> RTL backend, to allow using the GCC backend with the Clang frontend, but I'm not aware of any progress on this. You could ask on the gcc mailing list about it.

Thanks. The gcc mailing list mentioned the DragonEgg project
(http://dragonegg.llvm.org/), which translates GCC Gimple to LLVM
bitcode. In my understanding, bitcode means the LLVM SSA. My goal for
these translators is that I wanted to reuse existing passes from LLVM
and GCC, and such translations can link these two settings. This
DragonEgg solved this problem at a different level, because it
replaces the GCC optimizers with LLVM's. I was also pointed out that
RTL may not be a right IR for such as a translation, because it uses
machine-dependent information, while Gimple is much cleaner. I am not
sure if I understand the difference between RTL and Gimple. In
general, I still have this question about which IR I should use as the
source/target of the translation if I wanted to port one pass from one
compiler to the other one.

Hi Jianzhou,

Thanks. The gcc mailing list mentioned the DragonEgg project
(http://dragonegg.llvm.org/), which translates GCC Gimple to LLVM
bitcode. In my understanding, bitcode means the LLVM SSA. My goal for
these translators is that I wanted to reuse existing passes from LLVM
and GCC, and such translations can link these two settings. This
DragonEgg solved this problem at a different level, because it
replaces the GCC optimizers with LLVM's. I was also pointed out that
RTL may not be a right IR for such as a translation, because it uses
machine-dependent information, while Gimple is much cleaner. I am not
sure if I understand the difference between RTL and Gimple. In
general, I still have this question about which IR I should use as the
source/target of the translation if I wanted to port one pass from one
compiler to the other one.

gcc does its most important optimizations on gimple. Gimple was designed for
doing high level (i.e. not codegen) optimizations, and as such it is analogous
to LLVM IR. RTL is very low-level (close to the machine) and is analogous to
LLVM's "selection DAG", which is used by LLVM when generating assembler (via
llc for example).

Dragonegg converts gimple to LLVM IR. It turns off gcc optimizations by
default, but it doesn't have to: there is a flag,
   -fplugin-arg-dragonegg-enable-gcc-optzns
which results in gcc optimizations being left on. This doesn't have a huge
effect, because the gimple->LLVM IR conversion passes replace the gcc LTO
passes. The LTO passes are scheduled quite early, so only a small number of gcc
optimizations will have been run before the conversion. That said, I think
it is feasible to do the gimple->LLVM IR conversion after all gcc passes have
run (I did it like that at first, but needed to use the LTO infrastructure to
get hold of global variables in a reliable way, so I also moved function
conversion to using the LTO infrastructure) but it would require a bit of work.

Converting LLVM IR to gimple is doubtless possible, but doesn't interest me
personally.

Ciao,

Duncan.