Live data from Hacker News

Why undefined behavior may call a never-called function

kristerw.blogspot.com

131–140 of 183 posts

Re: Why undefined behavior may call a never-called function

#131

Earlier quoted context omitted.

These optimization opportunities aren't small gains. They have big consequences, for example when they cause code that would not be vectorized to be vectorized. Again, compiler authors don't add UB optimization for the fun of it. Patches to add theoretical optimizations that don't actually move the needle are routinely rejected from LLVM and GCC (as they should, because optimizations slow down compilation, so they ne…

If there were a simple and reliable way to say "make the program crash if we hit any of this UB, rather than optimising it completely away" I think that would make a lot of people happy.

LLVM already does this as much as possible. Look at how Clang inserts "ud2" instructions in dead code paths.

Re: Why undefined behavior may call a never-called function

#132
post #92

Earlier quoted context omitted.

The craziness for C optmizer tricks is in many cases plain phsycologic. As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome. Actually there is a remark from a famous compiler write (female), which I don't recal the name now, that C brough back into the stone age what the optimizers were already a…

Can you give some examples of optimization passes in clang/LLVM that you think are unnecessary?

I didn't say they aren't necessary, rather that the idea was already used in PL/8 during the 70's, a type safe safe systems programming language.

https://courses.physics.illinois.edu/cs426/fa2017/Papers/pl8...

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.87.4...

Re: Why undefined behavior may call a never-called function

#133
post #92

Earlier quoted context omitted.

The craziness for C optmizer tricks is in many cases plain phsycologic. As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome. Actually there is a remark from a famous compiler write (female), which I don't recal the name now, that C brough back into the stone age what the optimizers were already a…

> As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome. That hasn't been true ever since power consumption started mattering.

If it really mattered at that level, people would have already stopped trying to do Web based OS or applications for mobile phones.

Also Apple, Google and Microsoft would expose the complete set of mobile and watch OS APIs to C and C++ developers, which they don't. They are kept down to the bare minimum for the upper OS layers.

Re: Why undefined behavior may call a never-called function

#134

If you make one small change to this file you can cause clang and gcc to both prevent this from compiling if you are using warnings. namespace { void NeverCalled() { Do = EraseAll; } } or marking NeverCalled as static itself. Results in warning: unused function NeverCalled. In general this is best practice for functions defined and used in a single translation unit.

Very interesting. Thank you for sharing this!

Re: Why undefined behavior may call a never-called function

#135
post #92

Earlier quoted context omitted.

The craziness for C optmizer tricks is in many cases plain phsycologic. As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome. Actually there is a remark from a famous compiler write (female), which I don't recal the name now, that C brough back into the stone age what the optimizers were already a…

> As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome. That hasn't been true ever since power consumption started mattering.

If you mean takes 15ms vs 5ms to compile yes. However if you're talking executions speed those low hanging fruit optimizations were picked in the 1980's. What we're talking about here are optimizations that speed up some obscure benchmark on a disused architecture by 5%. Bonus no telling if performance is worse on next years silicon.

Re: Why undefined behavior may call a never-called function

#136

Earlier quoted context omitted.

The original ANSI C committee had no idea about modern optimization pipelines. If people had continually pushed back against undefined behavior back then, there's a good chance that by 2017 the result would have been that C would be dead , replaced by a language that allows for modern optimization techniques.

What language do you think would have replaced it? It seems to me that C had already won as the de facto systems language, long before any of these "modern optimisation techniques" cropped up. Optimisations that make it harder to use the language safely are downright dangerous in my book.

I would have been happy with Modula-2, Ada or Object Pascal as basis.

But better yet would have been Modula-3 or Active Oberon.

Re: Why undefined behavior may call a never-called function

#137
post #45

Earlier quoted context omitted.

That's a vital part of the setup. You could hypothetically link this compilation unit against another unit which included: void NeverCalled(); struct A { A() { NeverCalled(); } }; A a;

You don't even need C++, you can just use C and __attribute__((constructor)).

Which is a GCC specific extension and not ANSI C.

Re: Why undefined behavior may call a never-called function

#138
post #81

Earlier quoted context omitted.

>> if it was smart it would have figured out that the value never was initialized > But that's false Are you reading the same code the rest of us are? NeverCalled is never called. So Do is not explicitly initialized and therefore contains a null pointer because it's a static variable. Now compiler writers wanted their benchmark scores better so instead of crashing the program when Do is called, which happens in the u…

Go back to JavaScript, dear. You'll learn about real systems languages when you're older. Seriously. This just isn't how computers work. Main doesn't just get magically called in a vacuum. I don't see how a play project writing a compiler which is going to solve all those problems other compiler writers couldn't solve, while you don't even have a basic grasp of systems programming, helps your argument that you aren't…

[deleted]

Re: Why undefined behavior may call a never-called function

#139
post #44

Earlier quoted context omitted.

> Unfortunately, I'm also sure that we don't have the time to do it. And that really is the crux of the issue. Despite the significant amount of discussion around the problems of C UB, there is precious little work being done to actually "solve" the problems. https://blog.regehr.org/archives/1287 > Since we published the Friendly C proposal, people have been asking me how it’s going. This post is a long-winded way of…

I believe creating safer languages like: Go, Rust, Swift are also attempts to solve the problem. It doesn’t need to be C/C++

Agreed on both points. Still I think there would be room for a more C like language in the market. Rust in all its greatness is also very complex, gaining more of a C++ feeling to it. I don't think any of the new languages (including modern C) manage to replicate the feeling of simplicity and transparency of k&r c.

Re: Why undefined behavior may call a never-called function

#140
post #99

Earlier quoted context omitted.

There is absolutely no problem with optimizations being available. The problem is that the standard gives the compiler license to muck with the semantics of the program in highly non-intuitive and potentially dangerous ways, and this is true regardless of what flags are passed to the compiler. So I can't depend on anything working even if I specify -O0, at least not by the standard. I am entirely at the mercy of the…

> So I can't depend on anything working even if I specify -O0, at least not by the standard. I am entirely at the mercy of the benevolence of my compiler vendor. What you're basically saying is that you want semantics that's basically defined by the compiler vendor (or, more accurately, compiler/operating system/hardware trio), but you're pissed that the standard leaves it up to the compiler vendor as to whether or n…

No, uint32_t has been part of the C standard library since C99.
Post reply on HN