unpopular opinion: the kind of program we call an "assembler" is a disgrace and they're almost useless. a real assembler would perform register allocation for you and handle calling conventions.
55
38
268
Conversation
that's too high level though, like let's say your code cannot be abstracted with functions, or needs to do SIMD operations not exposed in intrinsics, or something
2
11
LLVM is also too low level, since it doesn't fully abstract away the C calling convention
2
8
It would be nice if it truly had full support for aggregates... you should be able to pass them by-value and get decent code conforming to the specified calling convention. It shouldn't be necessary to use weird attributes, manual memcpy and splitting up into scalar parameters...
1
6
It's beyond just the lack of C calling convention support. It essentially lacks proper support for them in general. It's also bad at handling languages with heavy usage of (tagged) unions like Rust. It's way too focused on being a Clang backend. Dealing with GC is probably worst.
2
5
Yep, I went through several iterations for Swift's llvm codegen for enums and no strategy is terribly great
2
2
I worked on Rust's compiler / stdlib for a while and spent a fair bit of time trying to get better codegen, especially for features I implemented like Vec, Rc, iterators, etc. I'm still frustrated with LLVM years later. It still doesn't have the planned noalias intrinsic... sigh.
1
2
This is pretty sad:
github.com/rust-lang/rust
bugs.llvm.org/show_bug.cgi?i
No one actually uses restrict in C, so it doesn't work. Rust's usage was quite conservative too. In theory, it could pervasively mark &mut T noalias and also many &T (since it's about memory dependencies).
Here's a long list of bugs found:
github.com/rust-lang/rust
I remember filing github.com/rust-lang/rust in 2014 excited that we could start communicating a huge amount of aliasing information and then it turned out even marking it on parameters was totally broken in LLVM. *shrug*
4