2 ms·

This would produce at least one warning for almost every nontrivial function in your program, even with your concession towards simplifying arithmetic expressio

This would produce at least one warning for almost every nontrivial function in your program, even with your concession towards simplifying arithmetic expressions.

ben_w 2y ago
Can you give an example? This is surprising, and I can't imagine such… but then, I never wrote a compiler or needed to examine the assembly from one.
- UncleMeat 2y ago
  Copy elision and dead store elimination are extremely common examples. Redundant bounds check elimination on containers is another. I'd consider hoisting outside of a loop also to be eliminating code. I suppose some of this depends on what you mean by "eliminating a line of code", as an optimizing compiler pretty quickly transforms the program into a state where any kind of 1:1 mapping between lines of code and instructions is impossible.
  - ben_w 2y ago
    I suspect I have misunderstood the point you were making in the previous comment, are not the first two already things one can get warnings for, and the third a useful thing to know you're doing redundantly? I don't think hoisting would be covered by this suggestion, pjc50 suggested deletion rather than moving. I read the proposal very literally, which also means I'm unclear what options you have in your final paragraph: Compile function as is; For each line, make a copy with that line missing and recompile; when this identical to the original, flag that line as "warning: optimised out of existence"
    - UncleMeat 2y ago
      This approach would increase compile times by an outrageous amount, since you now need to compile each function N times. Optimizing compilers can also produce different output but with identical semantics depending on a lot of heuristics. What happens when deleting a line of code produces different inlining or specialization decisions? What is a rigorous definition of "identical"? "Deleting a line" is also not the only way that unexpected and perhaps unwanted behavior from UB reasoning appears. Unexpected code motion is absolutely a thing that people have complained about. I don't think you can so quickly insist that things like hoisting are out of scope here.

This would produce at least one warning for almost every nontrivial function in your program, even with your concession towards simplifying arithmetic expressions.

ben_w 2y ago

Can you give an example? This is surprising, and I can't imagine such… but then, I never wrote a compiler or needed to examine the assembly from one.

UncleMeat 2y ago
Copy elision and dead store elimination are extremely common examples. Redundant bounds check elimination on containers is another. I'd consider hoisting outside of a loop also to be eliminating code. I suppose some of this depends on what you mean by "eliminating a line of code", as an optimizing compiler pretty quickly transforms the program into a state where any kind of 1:1 mapping between lines of code and instructions is impossible.
- ben_w 2y ago
  I suspect I have misunderstood the point you were making in the previous comment, are not the first two already things one can get warnings for, and the third a useful thing to know you're doing redundantly? I don't think hoisting would be covered by this suggestion, pjc50 suggested deletion rather than moving. I read the proposal very literally, which also means I'm unclear what options you have in your final paragraph: Compile function as is; For each line, make a copy with that line missing and recompile; when this identical to the original, flag that line as "warning: optimised out of existence"
  - UncleMeat 2y ago
    This approach would increase compile times by an outrageous amount, since you now need to compile each function N times. Optimizing compilers can also produce different output but with identical semantics depending on a lot of heuristics. What happens when deleting a line of code produces different inlining or specialization decisions? What is a rigorous definition of "identical"? "Deleting a line" is also not the only way that unexpected and perhaps unwanted behavior from UB reasoning appears. Unexpected code motion is absolutely a thing that people have complained about. I don't think you can so quickly insist that things like hoisting are out of scope here.