"Better" is subjective, as an LLVM is not always appropriate for most firmware.
Indeed, note gcc is sometimes intentionally Nerf'ed to suppress optimizations in favor of more repeatable code-motion behavior in real-time systems. Yes this can compile terribly inefficient binaries when inspected, but they are predictable and repeatable builds.
There is sometimes extremely good reasons to be able to inspect exactly what the assembly dump does, and know for sure it won't get randomly permuted in the compilation optimization/abstraction LLVM builds.
This concept is difficult for people who don't understand the subtle difference between guaranteed-latency schedulers, and real-time systems.
Clang is great for a lot of application level things performance wise, but firmware is often not one of those use-cases for really good reasons.
I guess it is true what they say, one day you must become a historian if you are around long enough. lol =3
Indeed, note gcc is sometimes intentionally Nerf'ed to suppress optimizations in favor of more repeatable code-motion behavior in real-time systems. Yes this can compile terribly inefficient binaries when inspected, but they are predictable and repeatable builds.
There is sometimes extremely good reasons to be able to inspect exactly what the assembly dump does, and know for sure it won't get randomly permuted in the compilation optimization/abstraction LLVM builds.
This concept is difficult for people who don't understand the subtle difference between guaranteed-latency schedulers, and real-time systems.
Clang is great for a lot of application level things performance wise, but firmware is often not one of those use-cases for really good reasons.
I guess it is true what they say, one day you must become a historian if you are around long enough. lol =3