Hello,
I was able to get a solution for my github issue, where I asked for C2000 support in clangd.
Therefore, I would like to ask if llvm would accept adding cl2000 compiler support to the clang frontend as it would greatly suffice our needs? We would also be happy to look into contributing with some guidance if we get a green signal for this. I would really appreciate a positive response 
Thanks,
Hi! I manage the MCU compiler team at TI responsible for the C2000 compiler (cl2000). Right now, we have no plans to add support for that into LLVM, even to the front end. It might require a significant amount of work, especially due to the 16-bit addressability issues.
Adding full support would obviously be a lot of work… but just the bits to get clangd working would be relatively minimal, I think.
LLVM has an experimental target policy (LLVM Developer Policy — LLVM 20.0.0git documentation), but we don’t have any equivalent clang policy for the frontend bits, and there isn’t any way in the build system to enable/disable a target.
My primary concern (and the reason I suggested a Discourse thread) is long-term maintenance; we can try to get some coverage with regression tests, but if we don’t have someone active in the community willing to back it, it’s likely to bitrot. That said, just the frontend bits is not that much code, so maybe we don’t care that much if it bitrots a bit… but I’d least like to have someone around who’s likely to respond to occasional questions.
@evodius96 If someone else does the work to write the initial patches, would you be willing to help with code reviews? Even the occasional comment from someone familiar with the target would go a long way.
Hi @efriedma-quic, @student433
If someone else does the work to write the initial patches, would you be willing to help with code reviews? Even the occasional comment from someone familiar with the target would go a long way.
Yes, my team can assist you with that.
Thanks!
Hi @evodius96, thank you for your response.
I work with @student433 on this project and we are considering to add support for C2000 to clangd.
I’m actually a bit surprised to hear that TI is not considering working on this, since your new CCS Theia IDE is also using the clangd language server.
Since there is no C2000 support in clangd right now, CCS Theia seems to generate a compilation database that just pretends a normal clang compiler is running, which results in issues whenever platform specific implicit defines etc. come into play.
To me it seems like adding support for C2000 in clangd is the only way to get proper C2000 support in CCS Theia.
Can you maybe share the current plans to improve C2000 support in CCS Theia?
Is TI working on a different solution that is not going to use clangd?
Support for non-llvm (TI proprietary) toolchain support with CCS Theia is limited. Presently Theia relies on a stripped-down compile command from the compilation database that effectively limits it to options common across both clang and TI proprietary toolchains, like ‘-I’ and ‘-D’. There are no immediate plans to enhance this support in clangd, and so if your team is willing to add it, we will be more than happy to consult and assist with the reviews.
@efriedma-quic based on your previous response on GitHub I understand the steps necessary to add the C2000 target as a new clang frontend.
However, I’m not sure how we should proceed regarding the different command line argument names for cl2000.
Is it possible to extend the compile command parser to understand the TI specific syntax (like --include_path to specify include paths) or is the compile command parser generic and explicitly limited to GCC style arguments?
If the latter is true, we might need to do some preprocessing of compile_commands.json before we can run clangd.
@evodius96 Thank you for explaining the current state of things at TI. From what I can see, the clang frontend code should not be that much work. I think the biggest issue is going to be to accurately deduct the correct predefines based on the compiler arguments.
This is where we might require your assistance in the future.
We’ll run some experiments as a first step and come back to you if need any consultation.
Can’t you just write your own driver that’d translate TI specific style options into equivalent clang ones (kind of what clang-cl does)?
Yes, that should work. I was not familiar with the different clang drivers, thank you for bringing that up!
Some of the TI specific arguments also have GCC-style aliases, so we might actually be able to get it work without needing the custom driver in the first step. We will have to play around with CMake to emit the options in this style though, so a proper driver would be better.