<div dir="ltr"><div><br></div><div>The qcc project that I'm working on compiles C code. It will leverage some backend to support plenty of popular targets. It is very small and very fast. What priorities of yours are not included in that list?</div><div><br></div><div>The only reason that TCG frontend code is not a compiler intermediate language is that it hasn't been embedded into any compiler yet. At least one known problem with it is that it only supports a single register return value from any function, which is not C99 compatible -- and that deficit means it's not even compatible with musl. ATM, it also has floating point support turned off. The more mods that I have to make to the input (to make TCG handle the full range of C99 C code), the more that I need to modify *every single TCG backend* to support those mods. So, in some sense, the more backends there are, the more of a headache it is. And the less likely that it will actually happen in reality.</div><div><br></div><div>Creating a compiler is a game of tradeoffs, of course. Yes, the most important thing to a user is that the compiler support their target CPU and file format. The nextmost important thing to users will certainly be a lack of compiler-introduced bugs in the output. Third is probably the code quality of the output in terms of speed. Then the speed of compilation. Then, for an open-source project, probably the clarity and obviousness of the code and algorithm.</div><div><br></div><div>I have been expecting that TCG, or whatever backend is selected, will produce slower code for a wide range of target CPUs. I have also been expecting to create by hand additional, user-selectable, much more optimized backends -- because *I* care very much about getting decent performance out of x86 code, at least. I have a lot of techniques I've developed over the years to beat gcc -O3 every time.</div><div><br></div><div>So, I am still probably a month away from beginning to select and deal with a backend. TCG is certainly still a possibility. I'm not married to the idea, but I haven't come close to rejecting it, either. But of course I want a backend that needs as little modding as possible, within the constraints of the game of tradeoffs, above. A backend that needs a lot less modding and produces more optimized code may be preferable to one that supports a huge handful of obsolete CPUs. Because each one of those obsolete CPUs may add a lot of additional work.</div><div><br></div></div>