Refactoring Clang - could this benefit Julia?

Internals & Design
1

I’m new to this community so first of all, Hi everyone!

I am a member of the Fortran Team at Arm and would like to draw your attention to the RFC that our team has sent today to llvm-dev/cfe-dev/flang-dev: [llvm-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM

TL;DR We would like to move the bits of Clang that could be re-used by other frontends to LLVM. Is this something that Julia could benefit from? Would anyone like to get involved? Your input (either here or, preferably, on llvm-dev) would be much appreciated!

Thank you,
-Andrzej

15 Likes
2

There are some bits of clang that could be useful for us, particularly around proper C ABI lowering. Our current code is based on LDC (e.g. julia/abi_x86_64.cpp at master · JuliaLang/julia · GitHub). However, the codegen part of our compiler is quite small, so it might not be worth the dependency. We do also have custom clang analyzer passes that I think could benefit from a cleaner separation of concerns in Clang (currently the analyzer is quite source-level, but I think with additional higher-level abstractions in Clang that abstract over syntax, but on C semantics, those kinds of things might become cleaner - not sure if that’s in scope for you).

That said, there are a few packages that depend on clang, notably https://github.com/JuliaInterop/Clang.jl and GitHub - JuliaInterop/Cxx.jl: The Julia C++ Interface, so I would imagine a more careful structuring of clang could help streamline those packages.

9 Likes
3

Thanks, this helps a lot!

We are currently focusing on the driver for Flang, but there’s infra code that’s used by both the driver and the frontend (e.g. Diagnostics, SourceLocation). Sadly there’s not that much overlap with what you mentioned :frowning: What we are proposing is a prerequisite for more code being shared/extracted from Clang, but it will take a while to get there.

2 Likes