3 ms·

> The code the compiler generates must have the same final result, but it doesn't have to actually work the same way. You're obviously correct, but I think thi

• cma 5y ago
  Doesn't this hurt forward compatibility to new architectures where there are more registers and it would be more efficient doing it through registers? Seems like automatic choice by the compiler should be default and if explicit control is needed some kind of attribute or something could be used to override the compiler's choice.
  • zorgmonkey 5y ago
    Not really because ABI's are already architecture specific so they already do stuff different for other CPUs. Similarly, their are already a variety of attributes that can be used to explicitly control the ABI of the top of my head things like packed structs and function calling convention are common and in several languages (C, C++, rust and zig).
• msbarnett 5y ago
  > You're obviously correct, but I think this ignores downstream costs of sufficiently magical compilers. If my compiler tunnels into a parallel universe, executes the code there, and returns the result, that's fine, but it's going to be enormously painful to debug. > Obviously very few developers (including myself) have an appropriate mental model of highly complex, speculative processor architectures that end up executing their code, but I do think there is at least some benefit to having a correspondence between the code you write and the code the compiler generates. It’s not really clear to me why you think this? Or at least, it’s not clear to me how you can write this without levelling the same complaint against essentially any C compiler written after the mid 1980s? Because for all the hand—wringing in the comments here about compilers generating code that doesn’t do what your C said it would do in the way you wrote it, that ship sailed decades ago. That quaint little integer addition loop you write in C will, as like as not, be exploded by the compiler into an unrolled stream of SIMD instructions and packed registers that doesn’t resemble what you wrote in the least, which the CPU may then further scramble and interleave, resulting in nothing remotely like what a naive person might imagine is a reasonable translation of what you wrote – and yet, debuggers remain broadly useful tools. And people have for decades now shown a strong desire to enthusiastically and with great speed drop compilers in favour of newer ones that performed better optimizations, which is to say, people have shown a strong preference for compilers that are good at generating code that looks nothing like what you wrote, provided the results are the same and the performance is as fast as possible. Turning a copy into passing a pointer that may later copy if and only if the compiler sees the possibility of a write coming is, in terms of modern optimizations, an absolutely conservative optimization that doesn’t routinely happen only because platform ABIs unnecessarily rule it out. Far from being a bridge too far, in terms of modern compiler behaviour it’s simple and low-hanging fruit which isn’t exploited even though far more exotic tricks are already the rule of the day.
• nwmcsween 5y ago
  GCC and LLVM already do this, the idea of what you wrote is still there, if you want to debug add debug info, DWARF exists for a reason.