Viewing profile — nikic

> Is there any implicit understanding in the community that byte types will inevitably be added to LLVM? Among the people who are familiar with such things, yes. An RFC on the topi…

That was ambiguously phrased. The point I was trying to make here is that we don't have the situation that is very common for open-source projects, where a project might nominally …

Yes, the Orc C API follows different rules from the rest of the C API ( https://github.com/llvm/llvm-project/blob/501416a755d1b85ca1... ).

This particular case isn't really due to pattern matching -- it's a result of a generic optimization that evaluates the exit value of an add recurrence using binomial coefficients …

This depends a lot on what you're doing with LLVM. If you are just using LLVM as a code generation backend for your language frontend, you generally do not need an LLVM fork. For e…

> LLVM is a trap. Is it? I think Rust is a great showcase for why it isn't. Of course it depends somewhat on your compiler implementation approach, but actual codegen-to-LLVM tends…

That's a great point. I initially thought we could assume no exposure for loads with non-pointer-compatible TBAA, but you are right that this is not correct if the memory has been …

That type punning through memory does not expose or synthesize memory. There are some possible variations on this, but the most straightforward is that pointer to integer transmute…

At least at a skim, what this specifies for exposure/synthesis for reads/writes of the object representation is concerning. One of the consequences is that dead integer loads canno…

> Interestingly, Windows on ARM hasn't made it up to Tier 1 yet. An RFC for that has been submitted recently: https://github.com/rust-lang/rfcs/pull/3817

One peculiar thing about the benchmark results is that disabling individual UB seems to fairly consistently reduce performance without LTO, but improve it with LTO. I could see how…

They do a bit more than that. One of the options (-disable-object-based-analysis under AA2) disables the assumption that distinct identified objects do not alias, which is disablin…

Fun fact: GCC decided to adopt Clang's (old) behavior at the same time Clang decided to adopt GCC's (old) behavior. So now you have this matrix of behaviors: * Old GCC: Initializes…

Where possible, undefined behavior at the LLVM IR level is always optional, controlled by various flags, attributes and metadata. Things like signed integer overflow, or even the f…

NULL == NULL was already defined -- but NULL <= NULL wasn't :)

Huh, this is interesting. Normally the reason to become a CNA is to reduce the amount of bogus CVEs that are issued for your project due to security researchers trying to pad their…

LLVM actually also supports instruction-level granularity for fast-math (using essentially the same mechanism as things like unchecked_add), but Clang doesn't expose that level of …

The background here is that "ctpop https://github.com/llvm/llvm-project/issues/94829 ).

> It's true that MSVC doesn't have an equivalent of -fno-strict-aliasing, but that's because it just doesn't apply optimizations that assume strict aliasing in the first place. Adm…

> People can (and do) point at the C spec for fault of this and it is true that if the C spec was more strict then these compilers would not have the free pass to do these crazy mi…

The main performance-critical undefined behavior in C is provenance. The rest can be removed without major performance impact. (Which is not to say they can't give you 10% on speci…

What's with RISC-V and these peculiar extension names?