When I purchase a game, I generally don't have time to play it.

We are not the same.

This may be why gaming is a few multiples larger an industry than film.

1. https://en.wikipedia.org/wiki/Curiously_recurring_template_p...

2. https://david.alvarezrosa.com/posts/devirtualization-and-sta...

3. https://llvm.org/docs/ProgrammersManual.html#the-isa-cast-an...

Comments URL: https://news.ycombinator.com/item?id=47344839

Points: 3

# Comments: 0

This was in regards to: https://www.ftc.gov/news-events/news/press-releases/2025/01/...

https://godbolt.org/z/Kb736onb4

  \*\* IR Dump After Expand memcmp() to load/stores (expand-memcmp) \*\*
  ; Function Attrs: mustprogress nofree norecurse nounwind willreturn memory(argmem: read) uwtable
  define dso_local noundef zeroext i1 @isAllZeros(ptr noundef nonnull readonly align 4 captures(none) dereferenceable(8) %0) local_unnamed_addr #0 {
    %2 = alloca %"struct.std::array", align 8
    call void @llvm.lifetime.start.p0(ptr %2)
    store i64 0, ptr %2, align 8
    %3 = load i64, ptr %0, align 4
    %4 = load i64, ptr %2, align 8
    %5 = icmp ne i64 %3, %4
    %6 = zext i1 %5 to i32
    %7 = icmp eq i32 %6, 0
    call void @llvm.lifetime.end.p0(ptr %2)
    ret i1 %7
  }

Filed https://github.com/llvm/llvm-project/issues/180991 which I think is what the author should do in cases like this (rather than a blog post).

Comments URL: https://news.ycombinator.com/item?id=46971969

Points: 1

# Comments: 0

https://eli.thegreenplace.net/2013/01/03/assembler-relaxatio...

There were a few cases IIRC around usage of the `.` operator which means something to the effect of "the current point in the program." It can be used in complex expressions, and sometimes resolving those requires multiple passes. So supporting GAS compatible syntax in more than just the basic cases forces the architecture of your assembler to be multi-pass.

That's not what I said; you're attacking a strawman.

My point was more so that some people prefer the madness that is -funsafe-math-optimizations, or happen to rely on UB (intentionally or otherwise). What even is "correct" in the presence of UB? What is correct in such case was left up to interpretation of the implementer by ISO WG14.

I had to move teams twice before a third team was able to say: this work is valuable to us, please come work for us and focus just on that.

I had to organize multiple internal teams, then build an external community of contributors to collaborate on this shared common goal.

Having carte blanche to contribute to open source projects made this feasible at all; I can see that being a non-starter at many employers, sadly. Having low friction to change teams also helped a lot.

Some were necessary (asm goto), some were not (nested functions, flexible array members not at the end of structs).

> UDB, bugs and all

Luckily, the kernel didn't intentionally rely on GCC specifics this way. Where it did unintentionally, we fixed the kernel sources properly with detailed commit messages explaining why.

> or were there any issues that might be considered as specific to the linux kernel?

Yes, https://github.com/ClangBuiltLinux/linux/issues is our issue tracker. We use tags extensively to mark if we triage the issue to be kernel-side vs toolchain-side.

> Did you end up building a gcc compatability test suite as a part of this?

No, but some tricky cases LLVM got wrong were distilled from kernel sources using either:

- creduce - cvise (my favorite) - bugpoint - llvm-reduce

and then added to LLVM's existing test suite. Many such tests were also simply manually written.

> Did the gcc project themselves have a regression/test suite that you were able to use as a starting point?

GCC and binutils have their own test suites. Folks in the LLVM community have worked on being able to test clang against GCC's test suite. I personally have never run GCC's test suite or looked at its sources.

Read section J.1.

They found a bimodal distribution in failures over the lifetime of chips. Infant mortality was well understood. Silicon aging over time was much less well understood, and I still find surprising.

https://llvm.org/docs/MLGO.html

EDIT (since HN is preventing me from responding):

> Some people care more about compiler speed than the correctness?

Yeah, I think plenty of people writing code in languages that have concepts like Undefined Behavior technically don't really care as much about correctness as they may claim otherwise, as it's pretty hard to write large volumes of code without indirectly relying on UB somewhere. What is correct in such case was left up to interpretation of the implementer by ISO WG14.

I had hoped one day to re-implement parts of LLVM itself in Rust; in particular, I've been curious if we can concurrently compile C (and parse C in parallel, or lazily) that haven't been explored in LLVM, and I think might be safer to do in Rust. I don't know enough about grammers to know if it's technically impossible, but a healthy dose of ignorance can sometimes lead to breakthroughs.

LLVM is pretty well designed for test. I was able to implement a lexer for C in Rust that could lex the Linux kernel, and use clang to cross check my implementation (I would compare my interpretation of the token stream against clang's). Just having a standard module system makes having reusable pieces seems like perhaps a better way to compose a toolchain, but maybe folks with more experience with rustc have scars to disagree?