Conversation

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.

1

1

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

Replying to

and

It's not only with infinite loops but also infinite recursion and there are implementation issues with stack overflow too. I don't think the situation before -fstack-clash-protection on *nix can be considered reasonable. It also still seems wrong in terms of the standard.

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

Replying to

and

sure, many things are a mess. returning to noalias, either it has a semantics or not at the LLVM level. assuming that it does, there'll be some set of optimizations that disrespect the semantics, and I doubt this set will be huge.

2

1

Replying to

and

some of the issues won't be load-bearing and it's not hard to get those fixed. the remaining ones may well be hard, but the LLVM community understands perfectly well that C/C++ are not the only use cases. anyway, the way forward is clear and probably not extremely difficult...