Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

and

Nah! There are two kinds of UB: UB in the IR that the compiler uses and UB in the language. LLVM has the former. That doesn't imply UB in the latter. It happens to imply that in llvm and gcc because of policy decisions.

Replying to

and

For example: introduce a pass that runs before llvm opt pipeline that removes all TBAA, changes all geps to int math, remove all nsw/nuw flags from int math, replace all undef's with 0, and 0-initialize all alloca's. That gets you very close to no UB.

Replying to

and

not really but it would reduce the amount of UB exploitation. there's a long tail scattered around many passes that you can't find so easily, requires a fine-toothed comb.

Replying to

and

Not sure that’s really true. WebKit’s LLVM-based FTL JIT encountered no such problems to my knowledge. High probability we would have known. We even ran tests with the full -O3 pipeline. Maybe there are bugs, but I wouldn’t conflate that with UB.

Replying to

and

To name one off the top of my head: You have to do something to sanitize float-to-int casts or else they become undefs if out of range. For a long time “array[x as usize]” with x: f64 could cause UB in safe Rust for this reason.

Replying to

There's also the perpetually annoying 'a function calling itself in an infinite loop is UB'

Replying to

Check out this example using a loop: gist.github.com/thestinger/7e6 LLVM considers noreturn to be an effect, and yet it doesn't consider a function that *may* not return to have an effect. This is a bug, but an intentional one because they chose to keep an unsafe optimization around.

gist.github.com

infinite.c

GitHub Gist: instantly share code, notes, and snippets.

Replying to

They properly preserve functions that are pure but not nounwind, such as a chain of them like foo(); foo(); foo(); being optimized to foo(); but never being completely removed. They are missing an attribute for 'returns' or 'halts' and yet optimize without checking anyways.

Replying to

So, even though it's known that this is broken for many years, they have kept the optimization enabled. No one has been motivated to deal with implementing a 'halts' attribute and adding support for detecting / propagating it in the function attribute pass and making it required.

Replying to

I think if the broken optimization was disabled, someone would become motivated to get the infrastructure implemented to enable it again. There are many known bugs like this. The burden is placed on people who want correctness to fix all optimizations, instead of the other way.

4:55 AM · Apr 16, 2019Twitter Web Client

Replying to

Really, an optimization that has known to be broken for years should just be disabled at some point. If people care about the optimization, they can fix the known bugs and get it enabled again. It's an issue of priorities and values. That would need to change for it to be sane.

Replying to

agree