Conversation

Replying to

and

restrict, type punning, pointer provenance, etc. are poorly defined for C so LLVM ends up with semantics based around how they felt like interpreting the C standard. It's not really expected to work and be fully well defined. Rust has much different expectations from LLVM.

2

2

Replying to

and

we're formalizing all of this in alive2

1

4

Replying to

and

I think the issue will generally be that optimizations consuming alias analysis are wrong. However, they didn't get enough information to noticeably break code until most of the pointers started being marked as noalias which is what happens with Rust if it's done aggressively.

1

1

Replying to

and

Most of the complexity where everything can go wrong are the optimizations consuming the information. Compared to that, the alias analysis deciding whether to answer NoAlias doesn't seem particularly hard to get right. Of course, maybe it's still broken or propagation is broken.

1

1

Replying to

and

Rust was even hitting lots of these issues just from marking parameters as noalias, not even from applying it aggressively. LLVM happily generates scoped noalias metadata itself when inlining, etc. LTO + nearly all pointers marked noalias seems inherently prone to finding bugs.

2

1

Replying to

and

I looked quickly at the uses of NoAlias in llvm-project/llvm/lib, it's not that broadly used, I doubt the number of misuses is anything close to vast

1

1

Replying to

and

if there are bad optimizations that are giving performance wins, then that's the hard case to get fixed

1

1

Replying to

and

we're still working on UB-related bugs we found like seven years ago because they fire ubiquitously and matter, and getting the same wins in other ways isn't so straightforward. this could be like that...

1

2

Replying to

and

I really liked the infinite loop / infinite recursion example that's now finally fixed. It was a pretty shocking bug in a language like Java or Rust. In C, no one cares. The code is already wrong and horribly broken anyway. Just needs to go fast and appear to still mostly work.

2

2

Replying to

and

it's not that nobody cares, it's that the standards committees explicitly decided to make compiler writers' jobs easier by making certain loops UB, and the LLVM compiler writers took advantage of the allowed leeway

1

Replying to

and

That's true for C++ but it was definitely a correctness bug in Clang for C.

11:09 PM · May 5, 2021Twitter Web App

Replying to

and

well, I explored that somewhat here and it's not necessarily as clear-cut as you suggest blog.regehr.org/archives/161

2

1

Replying to

and

and as far as I can remember I found three major C implementations that would terminate an infinite loop, so even if you're sure about the standard then this ends up being one of those things where the standard is wrong since it disagrees with prevailing practice

1

Show replies