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.
Hello,
We have just added support for the c2000 architecture to get clangd working. I have started a pull request in github and it would be really nice if you could all have a glance and review it. Please follow the link here :
Please feel free to suggest changes or modifications.
Thanks,
Apologies for missing this RFC â it was posted to LLVM Project and didnât tag Clang, so it was entirely off my radar.
Itâs unclear to me what the benefit is for having frontend support for a target that the backend does not support. Can you help explain the motivation for this a bit more?
I share the maintenance concerns. What is the long-term plan for preventing bitrot?
Also, Iâm concerned about the user experience of clangd supporting something you canât actual compile for with Clang. Thatâs a novel new direction. CC @HighCommander4 @beanz @kadircet as clangd maintainers for additional opinions.
One thing that has struck me over the course of ~4 years of keeping an eye on clangd issues is that there does not seem to be a C/C++ language server based on gcc, nor any proprietary compilers other than Microsoftâs (that Iâve come across).
As a result, most people who use gcc or various proprietary compilers to build their C/C++ code and want a language server turn to clangd (or other clang-based language servers like ccls). In many cases theyâre able to get it to work â sometimes more easily (clang supports the same target so itâs mostly a matter of passing the right --target flag and picking up the right system includes), sometimes less so (manually defining target-specific macros and such).
I think it would make sense to view clangd as being in a category of âfront-end onlyâ clang-based tools, along with a few others like clang-tidy and clang-include-cleaner. The use cases for these front-end only tools differ from actual compilation in a couple of important ways:
As such, and especially given the relative lack of alternatives, I would argue for using clangd (and other âfront-end onlyâ tools) on a C/C++ codebase that you cannot build with clang to be considered in scope.
Interesting, thank you for sharing!
This is actually part of what concerns me about supporting targets for which we have no backend; that is mostly about supporting those vendor-specific macros (along with the vendor-specific implementation limits and type choices). Reviewing that code is often challenging due to a lack of vendor documentation to verify behavior against. Once you have the target in place, then you have to continually maintain the target as the standards evolve and change things like limits.h or other standards-mandated environment macros.
I generally agree with what youâre saying, but that presumes users arenât filing issues with us for those false positives, which increases our maintenance burdens further.
I have to think about this more, but I can definitely see where youâre coming from and the value it could bring. But I think we may have to come up with some new policies to support it too â for example, do we aggressively remove support for a âpseudoâ target if we start to get issues filed against it and nobody is actively maintaining it, or are we expecting to support it long-term once weâve released it?
Another question is: if the utility is for clangd, should this be part of clangd as opposed to clang itself? e.g., if you try to pass the target to clang, you get the usual unknown target errors because thereâs no backend LLVM support for it; but clangd provides the various macros, etc?
Getting an error when you try to compile with clang seems fine, but it would be nice if clang-tidy and other âfront-end onlyâ tools worked in addition to clangd.
From a code organization point of view, perhaps that could take the form of the target-specific code living in the same place as other targets (libDriver and such), but annotated with a âfront-end onlyâ flag?
Yeah, thatâs a fair point.
That would be a pretty reasonable place for it to live. However, I think weâd want to not list it with -print-targets (Compiler Explorer); there may be other tweaks weâd need to make.
Ultimately, I think this deserves a Clang RFC. Not one about TI C2000 specifically, but about whether we want to have âpseudoâ targets at all. If we agree we want to support such a thing, then TI C2000 seems like a great test case for the idea. WDYT?
I think that supporting a new target with no backend support, especially one with specific hardware dependencies and potentially specialized toolchain requirements, introduces a significant maintenance burden.
While we recognize the importance of TI C2000, the user base is relatively specialized compared to other supported targets.
As outlined, the changes are relatively straightforward:
The SDK provider or community of the target could maintain a fork of llvm-project and provide tools like clang-tidy and clangd.
Downstream maintenance allows for a closer connection to the TI C2000 user community.
Coincidentally, I have read this yesterday from We are destroying software - <antirez>
We are destroying software by no longer taking complexity into account when adding features or optimizing some dimension.
The SDK provider or community of the target could maintain a fork of llvm-project and provide tools like clang-tidy and clangd.
This is a concern of ours (TI) as well since we are presently not able to take on this long-term responsibility for a feature that we knew would present complications. While Iâm happy to see there is interest for folks in the community to assist here, if there is no strategy for this long-term maintenance than I would be inclined not to upstream this support just yet.
Another question is: if the utility is for clangd, should this be part of clangd as opposed to clang itself? e.g., if you try to pass the target to clang, you get the usual unknown target errors because thereâs no backend LLVM support for it; but clangd provides the various macros, etc?
Hi, since I am handling the changes over the pull request, I think I can safely say that adding support to clangd partly makes it so much easier for the future develops to add flavours. -cc1 generates its own quadruple when a target is defined or a supported driver is detected.The target is needed in place because one of the main jobs of clangd in concern with code navigation is to have target features resolved in a project. Additionally, a lot of vendor specific flags that are defined in the customized toolchain are also paired with the clang --target that would make clang a lot more versatile without comprimising any existing support. So as verified, there are absolutely no errors or discrepancies while running clang with these targets, even without LLVM backend support.
Even I strongly believe that clangd is a glued component of frontend and consequently, clang-tidy and any other frontend tools will also work automatically then without making any explicit changes for them; as I have verified.
Ultimately, I think this deserves a Clang RFC. Not one about TI C2000 specifically, but about whether we want to have âpseudoâ targets at all. If we agree we want to support such a thing, then TI C2000 seems like a great test case for the idea. WDYT?
As for long-term maintainance and policy questions, I entrust you all to take a wise decision:)
I would like to know if a green light for an RFC is underway? And in that case, if I should start it or is anyone else planning to do it?
Hi @evodius96, I believe TI has already announced that the existing CCS IDE (Eclipse-style) will be deprecated and things will be completely switched to CCS Theia this year. As I assume, TI plans to have a more reliable platform specific dummy compile_commands.json generation in future that would not need this upstream change. But in current state, for ex-CCS and general IDE users, it would be quite useful for such support. And hence, would be really nice if long-term maintainence could be taken up. But I understand this is not in your current plans, but hopefully, it works out in this discussion somehow.