Andrew Kelley
@lritter interesting perspective. I would rather deal with the lack of C ABI support in LLVM bitcode than deal with C language limitations.
anyway, given this, maybe targeting zig isn't such an awful idea after all since it does solve the C ABI problem and has well-defined semantics for various things that are compiler extensions in C, such as arbitrary-width integers, all float sizes on all targets, SIMD, and various other things.
Leonard Ritter
@andrewrk problem statement? it works fine but it could be better. LLVM is too much work because of lack of C ABI support.
Andrew Kelley
@lritter zig does not have any optimization passes currently. It's also designed with human maintenance in mind with no regards to being the target of machine generation.
what's the problem statement vs the C backend? or vs llvm bitcode?
Leonard Ritter
@andrewrk oh by the way, since i'm skipping LLVM for the new compiler, the only backend i work on now is C, and only GCC can optimize this crap r/n.
would it make more sense to target zig instead, and is it even feasible?
generated code looks like this:
https://gist.github.com/paniq/2dc23f916909519326374c769b04cc92
(presently #line instructions are missing; i would like to provide column info as well tbh but cpp doesn't let me)
it only depends on this header file:
https://hg.sr.ht/~duangle/scopes/browse/include/noir.h?rev=tip
you see, lots of cpp macro use.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.