1. 25
  1. 4

    I love Ralf’s posts. So easy to follow and interesting. His post on uninitalized memory I’ve gone back to many times. https://www.ralfj.de/blog/2019/07/14/uninit.html

    1. 1

      I’m not an expert in compilers, so take this with a pinch of salt. If it was my compiler, I would like to get actual data on the effectiveness of these provenance-based optimizations so I could evaluate if the additional complexity in the compiler would be worth it. It feels like a feature that is vulnerable to scope creep (already adding provenance to integers now, so what’s next?)

      1. 1

        On the integers or pointers having provenance trilemma, maybe all three optimisations (but slightly less aggressive versions) could be allowed by making provenance be “set of allocations into which this may point” rather than “the allocation into which this points”

        So normal integers that didn’t come from pointer arithmetic would have {} as their provenance set so all algebraic transforms on them are permissible. Arithmetic operations on integers have to propagate the provenance sets.

        Then in the example program, iq has provenance set {q}, ip has provenance {p} to begin with. Then when the common sub expression elimination wants to replace iq with ip, it has to change ip’s provenance to {q,p} in order to be allowed to do so. Now other operations see q as being in the provenance set for ip and don’t attempt to ignore accesses to q through it.