I'm certainly not saying that it can't be done or that it isn't useful but that you're understating how much needs to be changed and the impact of it. Memory corruption also doesn't become predictable, just *less* impacted by optimization. It's still always going to be impacted.
Conversation
Here's something that's undefined: accessing uninitialized data.
int a; if (cond1) { a = 5; } else { if (cond2) { a = 10; } } use(a); do_other_stuff(); use(a);
Lets say that cond1 & cond2. Should both calls to use(a) be guaranteed to read the same value from uninitialized data?
2
1
2
Of course they should see the same value. Holy cow you’re throwing the easiest examples at me. It’s like you’re making my point for me: that this is easy to fix but that some people need compiler educations.
1
2
Okay, and that also means that using MADV_FREE in malloc and elsewhere is not possible either, which is a massive performance cost. Uninitialized memory can and does change value at runtime beyond just compiler optimizations avoiding saving uninitialized data via spill / restore.
2
3
That's likely glibc what is going to be doing for their stack cache since MADV_DONTNEED is a significant performance cost for their implementation, and it doesn't become a non-issue if restricted to malloc since it still means that uninitialized memory can change between reads.
1
4
Reading uninit data being undefined instead of locking it to an unspecified value permits massive optimizations like MADV_FREE and more efficient register allocation/spilling. Similarly, other memory safety issues being undefined permits optimization / freedom of implementation.
1
5
This Tweet was deleted by the Tweet author. Learn more
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.
1
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".
1
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.
There you go again, making perf claims without evidence.
1
It's hilarious for you to say that after you've just made a whole bunch of totally unsubstantiated claims about how optimization and LLVM code generation works that are completely untrue. You keep accusing people disagreeing with you of being ignorant but it's just projection.
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.
1
1
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.
1
Show replies