Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

I think this is one of the issues... saying that things are optimizations without citing even a single perf number. I still think that the biggest perf regression from -fno-bullshit would be the loss of strict aliasing.

Replying to

But folks describing things like llvm's undef or signed overflow as an "optimization" is disingenuous since *lots* of code doesn't benefit from those "optimizations".

Replying to

There's nothing disingenuous about saying that an optimization is an optimization. Many of the things that have been mentioned in this thread have a substantial impact on optimization including the basic memory safety guarantees, which optimizers lean on very heavily.

Replying to

There have just been a whole bunch of threads about these issues. It's you being disingenuous by picking out 2 specific things that are not a huge part of how optimizations are implemented. No one has claimed that those 2 things enable major optimizations. It's a strawman.

Replying to

I have a large list of things that don't enable major optimizations. Not sure which 2 things you think I'm picking out. So I'll repeat my point again: the UB feature that most helps perf is strict aliasing. Everything else is crumbs.

Replying to

The basic memory safety guarantees provide a lot more broadly used information about memory dependencies / aliasing than type-based aliasing metadata. Even the guarantees for pointer arithmetic have a huge impact. Just try compiling code using iterators without those guarantees.

Replying to

Simply taking away the basic memory safety and pointer arithmetic guarantees forbids most code motion (like hoisting out of loops), makes the compiler unable to see that tons of loops terminate or only access within the bounds of an object, etc. It kills most loop optimizations.

Replying to

Even the simple loop optimizations, not just more aggressive things like unrolling and vectorization. The optimization stack is based on basic guarantees from the assumption that memory safety isn't broken. No data races, no out-of-bounds accesses, no use-after-free, etc.

Replying to

That’s just not true. Again: if you think you’re right, get very specific, and I can help you understand.

Replying to

I don't need you to help me understand anything. Ignoring what I say and instead just cherry-picking a statement that is backed up by facts isn't arguing your point. If you permit out-of-bounds accesses, data races, etc. the compiler has to assume memory changes at any point.

8:42 PM · Apr 16, 2019Twitter Web Client