4 ms·
Does this mean that compilers have given up on processing GOTO if it is written directly by a person, but are fine in analyzing code generated in Intermediate c
by whitten 2y ago
Does this mean that compilers have given up on processing GOTO if it is written directly by a person, but are fine in analyzing code generated in Intermediate code from GOTO-less code ?
- bregma 2y agoNot at all. The compilers I'm familiar with (and my dayjob is maintaining compilers for a commercial OS) all just emit a phi node and construct basic blocks for all flow control constructs. By the time you're deep in the IR you have no idea if it was a do-loop, a for-loop, a while loop, a loop with continue and break statements, a series of deeply-nested if-statements, and aggregate initializer, or a goto. The people who religiously avoid the use of gotos are more often than not just cargo-culters.
- Findecanor 2y agoOn the contrary. Many passes in a compiler are simpler if the control-flow graph is reducible [1], which it is guaranteed to be if the program had been written in structured programming without any gotos. It is just that "goto" is closer to assembly code, and therefore used in intermediary code representations inside the compiler for that reason. But if the compiler had made sure beforehand that the control flow is reducible (and don't break that in an intermediary pass), then it will remain so. I find that most uses of gotos in source code are still reducible control-flow, but which had just not been expressible using structured programming constructs in the language. For example jumping out of nested loops, "for-else" and error handling. It is very rare that you see "spaghetti code" in practice. 1: https://en.wikipedia.org/wiki/Control-flow_graph#Reducibility https://en.wikipedia.org/wiki/Control-flow_graph#Reducibilit...