Pointers Are Complicated II, or: We need better language specs

Post by TrianguloY » Mon, Dec 14, 2020, 9:33 PM UTC

gizmo686 wrote: post #27

TrianguloY wrote: post #26

Earlier quoted context omitted.

And I agree, with an UB the original code is undefined and so any optimization is not right nor wrong, simply keep that UB. But then, why such a long article for a code whose second line is a UB ('p+1' is undefined)?

uintptr_t ip = (uintptr_t)(p+1); Is perfectly defined. What is undefined is converting ip back to a pointer and writing to it, which the original program never does.

  I mean, if a==b and you do *a=1 you can replace it with *b=1, but then you need to keep the information that 'a' was written to, so other optimizations (the third one) don't think it wasn't. Or am I missing something else here?

Post by dvt » Mon, Dec 14, 2020, 9:36 PM UTC

klodolph wrote: post #22

dvt wrote: post #8

First of all: fantastic article . In-depth, insightful, and the examples are absolutely top-notch. On the razor's edge between accessible and profound. Hats off to the author. I will say that the problems seem to lie in a few interesting interlanguage quirks, and not so much on language specs . For example, LLVM and C have different definitions of "undefined behavior"[1] -- this is pointed out when looking at the `po…

> As a side note, I'd be curious what happens when LLVM sees something like: `void p = &p` which is a self-referential pointer. What does it deduce about it? Does it optimize it away? Why would it do anything special here? This is not really different from something like this: struct a { struct a *p; }; struct a x = { &a }; The only real difference is that the void version involves a cast, because the type is otherwi…

Post by gens » Mon, Dec 14, 2020, 9:46 PM UTC

klodolph wrote: post #31

gens wrote: post #19

Earlier quoted context omitted.

If 'b' is actually used then the compiler has to put 'a' in memory. Theoretically. He says that b is not changed, and does not "escape" (the scope of the code in question). In that case b is useless, and thus it doesn't really even exist. A compiler can "collapse" a lot of code into a fraction of it. That's a part of the "optimizing" part of "optimizing compiler". A compiler can put a value in a register. A compiler…

> If 'b' is actually used then the compiler has to put 'a' in memory. Theoretically, no—the “as if” rule applies. In practice, also no, because real compilers perform escape analysis and there are aggressive optimization passes for eliminating dead loads and dead stores. Just like the compiler can optimize out b and replace it with a reference to a, the compiler can optimize out the value stored in a but keep the ref…

Post by klodolph » Mon, Dec 14, 2020, 10:00 PM UTC

gens wrote: post #36

klodolph wrote: post #31

Earlier quoted context omitted.

> If 'b' is actually used then the compiler has to put 'a' in memory. Theoretically, no—the “as if” rule applies. In practice, also no, because real compilers perform escape analysis and there are aggressive optimization passes for eliminating dead loads and dead stores. Just like the compiler can optimize out b and replace it with a reference to a, the compiler can optimize out the value stored in a but keep the ref…

That is what i said, that it can be optimized away. "exist" is the wrong word, "is useless" would be better. It is like.. you have a spanner in a box labeled "a" and you have a box "b" that has a piece of paper that says "look in a". You ask for a spanner and you get told to look in box "a". The box labeled "b" is then completely useless. One day some guy, weirdly named "compiler", decides to trow away box "b", and n…

Post by simias » Mon, Dec 14, 2020, 10:17 PM UTC

mjevans wrote: post #21

dvt wrote: post #8

First of all: fantastic article . In-depth, insightful, and the examples are absolutely top-notch. On the razor's edge between accessible and profound. Hats off to the author. I will say that the problems seem to lie in a few interesting interlanguage quirks, and not so much on language specs . For example, LLVM and C have different definitions of "undefined behavior"[1] -- this is pointed out when looking at the `po…

As usual; if a compiler knows about undefined behavior I would much rather it throw an error rather than optimize something the programmer didn't intend based on the compiler out-smarting a human's ability to be specific.

    void do_stuff(int *some_ptr) {
        do_substuff(some_ptr);

        *some_ptr += 2;
    }

    static void do_substuff(int *some_ptr) {
        if (some_ptr != NULL) {
            *some_ptr = 10;
        }
    }