2 ms·

> And through all of this, the compiler should also eject files that carry enough information to allow debuggers to make sense of the compiled code, unwind the

> And through all of this, the compiler should also eject files that carry enough information to allow debuggers to make sense of the compiled code, unwind the optimizations when the users asks, and present a coherent version of what is going on. You can't do this because some optimizations can't be seen through; most obvious one is identical code merging. If you're in a merged function then you don't know which of the original source lines you're looking at. I'd like to see a system which only had optimized compilation and used an interpreter for debugging.

int_19h 2y ago
You can do that by having several different trampolines for the merged code that stash away a unique cookie on the stack to distinguish which function the code is currently executing. This is not zero-overhead, of course, but one can argue that the slight overhead is worth it given better error reporting and increased debuggability.
bsder 2y ago
> If you're in a merged function then you don't know which of the original source lines you're looking at. Then don't do that optimization. How much is gained versus the grief that is caused? Even when I did a lot of embedded device coding, I don't think that optimization ever saved me more than a couple dozen bytes of code. And, as you point out, the optimization is stupidly difficult for debuggers to to unwind. This is one of the disconnects of modern optimization. There is no good backpressure from downstream tools to say "Oy. That optimization is going to make our lives difficult. If you can't demonstrate a significant improvement, don't do it."
- astrange 2y ago
  Indeed, you can just not do it for important things - usually the error paths leading to a crash or exit. It's important for embedded software though. But that was a bad example; I should've said tail calls. Which are much more common and more important, because avoiding them blows out the stack for recursive code.
deleted 2y ago
[deleted]

int_19h 2y ago

You can do that by having several different trampolines for the merged code that stash away a unique cookie on the stack to distinguish which function the code is currently executing. This is not zero-overhead, of course, but one can argue that the slight overhead is worth it given better error reporting and increased debuggability.

bsder 2y ago

> If you're in a merged function then you don't know which of the original source lines you're looking at. Then don't do that optimization. How much is gained versus the grief that is caused? Even when I did a lot of embedded device coding, I don't think that optimization ever saved me more than a couple dozen bytes of code. And, as you point out, the optimization is stupidly difficult for debuggers to to unwind. This is one of the disconnects of modern optimization. There is no good backpressure from downstream tools to say "Oy. That optimization is going to make our lives difficult. If you can't demonstrate a significant improvement, don't do it."

astrange 2y ago
Indeed, you can just not do it for important things - usually the error paths leading to a crash or exit. It's important for embedded software though. But that was a bad example; I should've said tail calls. Which are much more common and more important, because avoiding them blows out the stack for recursive code.

deleted 2y ago

[deleted]