"Native IR" Back End

[wchilders-nvidia]

Currently the EDG compiler project lacks a back end for the EDG front end that's capable of producing an executable without using of an external C or C++ "host" compiler.

This increases compile times, testing times, and install complexity as it requires a host compiler to be present. It also poses challenges for compilation of libraries using coroutines, exception compatibility, and platform ABI-compatibility.

There are a number of options for how to address this (including to not address it). The two that are most dominate in the open source ecosystem are LLVM and GIMPLE. There's also upcoming improvements in the LLVM ecosystem's MLIR space, primarily the CIR, MLIR dialect.

While a GIMPLE-based implementation would hypothetically be possible with an external GPL-licensed process (that consumes EDG textual IL) or a GPLv3-variant of the front end and resolve many of the above concerns, it would not improve the situation much in terms of "compiler as a library uses"/avoiding a host program as a dependency (outside of the use cases that could tolerate a GPLv3 license, which could directly embed such a program/skip the IL Write -> Read).

LLVM we both share a license with and has a long history powering Clang and many other compilers. However, MLIR has emerged for higher level optimizations and the focus seems to be shifting towards CIR (although it's immature).

It seems like the best bet would be a CIR back end, but I'm opening this because I want to see what other takes or perspectives are out there and get feedback on the above.

[mborland]

Looks like CIR came out of incubation earlier this year: https://github.com/llvm/clangir. Might be helpful to its further development to have a second implementation being worked on.

[SamuelMarks]

FWIW: Opened two PRs this week to try to initiate this discussion

LLVM (LLVM IR) backend: #221
gcc (libgccjit) backend: #239

They both (basically) work.