working on a new compiler and I hadn’t really noticed before how many varieties of “side effect free” there are. there’s at least “safe to speculate,” “safe to eliminate,” and “safe ...
@nprofile1q... sometimes GCC goes a bit too far in eliminating things even when they have visible effects on the output of the program.
For example it eliminated a `malloc/free` pair that was used to return false when allocation failed. It transformed that function to always return true, which changed the output of the program on stdout. A volatile store to an `intptr_t` global "fixed" it.
I can see why such optimisations might be desirable (e.g. if there is a branch where the pointer is untouched, and upon inlining the branch goes away), but they are unexpected for the programmer (I'd consider allocating memory a side effect, because it is directly observable, and can even crash your programs or another if you allocate too much).
If C has a different idea what a side effect is, that is probably too abstract (and I can't confidently say I know C anymore). Probably time to read the C standard again.
If you are building a new language I'd suggest making it possible to explicitly annotate side effects in function signatures that are visible to documentation and editor tooling, and when a similar optimization is made without any inking or specialising, then a warning must always be emitted, because it very likely points to a bug.
I'd also suggest making an "I really want the compiler to consider this side effecting and keep it" a first class notion, without having to resort to hacks. (E.g. `OCaml` has `Sys.opaque_identity` which gets erased at a late stage, and otherwise considered side effecting).
For example it eliminated a `malloc/free` pair that was used to return false when allocation failed. It transformed that function to always return true, which changed the output of the program on stdout. A volatile store to an `intptr_t` global "fixed" it.
I can see why such optimisations might be desirable (e.g. if there is a branch where the pointer is untouched, and upon inlining the branch goes away), but they are unexpected for the programmer (I'd consider allocating memory a side effect, because it is directly observable, and can even crash your programs or another if you allocate too much).
If C has a different idea what a side effect is, that is probably too abstract (and I can't confidently say I know C anymore). Probably time to read the C standard again.
If you are building a new language I'd suggest making it possible to explicitly annotate side effects in function signatures that are visible to documentation and editor tooling, and when a similar optimization is made without any inking or specialising, then a warning must always be emitted, because it very likely points to a bug.
I'd also suggest making an "I really want the compiler to consider this side effecting and keep it" a first class notion, without having to resort to hacks. (E.g. `OCaml` has `Sys.opaque_identity` which gets erased at a late stage, and otherwise considered side effecting).
1