4 ms·

I pretty strongly disagree with these quotes you have here. You don't need UB to do optimization, in fact because of UB in C many forms of optimization are impo

I pretty strongly disagree with these quotes you have here. You don't need UB to do optimization, in fact because of UB in C many forms of optimization are impossible in C because of aliasing uncertainty. If things are defined to not alias then even though things are fully defined there is a lot more optimization that can be performed by not reloading variables from memory and instead using local cached-in-register copies of variables. This is why naive Rust can in some cases be faster than naive C (without using of restrict keyword) and this will only improve with time as compilers better support this.

puffoflogic 5y ago
> If things are defined to not alias ... What do you call it then when you put aliasing pointers into pointer variables "defined not to alias"? Can you explain how this reduces UB?
- foxfluff 5y ago
  I think they're trying to say that if your language prevents aliasing (i.e. pointers by definition do not alias and it is impossible to make them alias), then the compiler doesn't need to worry about it. C doesn't prevent aliasing, therefore the compiler has to worry about every case of aliasing that isn't undefined. But it's not the UB here that prevents optimization, it's precisely the fact that aliasing is (sometimes) defined. If it were always UB, the compiler wouldn't ever have to worry about it... but that'd require some interesting changes to the language to keep it usable. Definitely not backwards compatible changes.
  - puffoflogic 5y ago
  - andrewla 5y ago
    > pointers by definition do not alias and it is impossible to make them alias This is equivalent to saying that pointer arithmetic is disallowed. Pointers are by their nature in the C virtual machine offsets into a linear memory space, so for any two pointers, x and y, there exists a c such that (ptr_t)x+c == (ptr_t)y, and thus there can always be aliasing.
    - gpderetta 5y ago
      Actually no, the C abstract machine is not contiguous. If x and y point inside distinct objects (recursively) not part of the same object, there is no valid c that you can add to x to reach y. edit: allowing that would prevent even basic optimizations like register allocation. edit: s/virtual/abstract/
      - andrewla 5y ago
        The C abstract machine requires reversible transformations from pointer to integral types (7.18.1.4 in C99, 3.3.4 in C90, the first ISO standard). Practically speaking modern devices are in fact mostly flat, so you can of course do this, although you do brush up against undefined behavior to get there.
        wbl 5y ago
        Pointer provenance is more complex and subtle.
        int_19h 5y ago
        Reversible transformations don't imply a flat address space. All it means is that there's an integral type with enough bits to record any address in them.
      - Shikadi 5y ago
        What is the c virtual machine? I thought there wasn't one
        foxfluff 5y ago
        They mean the abstract machine, in terms of which the semantics are defined.
    - skissane 5y ago
      > Pointers are by their nature in the C virtual machine offsets into a linear memory space Historically, many platforms - such as Multics or Windows 3.x - didn’t have a linear memory space, they had some kind of memory segmentation. The industry has largely moved away from that towards the flat address space model. Go back to the 1980s, it was still a much bigger thing, and people used C on those platforms, and the standard was written to support them. The actual detailed control of memory segmentation is inherently non-portable so cannot be addressed by the standard, but the standard defines pointer arithmetic in such a way to support those platforms - pointer arithmetic on unrelated pointers is undefined, because if the pointers belong to different memory segments the results can be meaningless and useless.
bee_rider 5y ago
See also decades of Fortran performance dominance, only overcome by throwing a gazillion C programmers at the problem.
- pjmlp 5y ago
  In theory, because those gazillion C programmers happen to misuse restrict, so in the end it mostly ends up in flames.
- gpderetta 5y ago
  but doesn't Fortran get away with it exactly because argument aliasing is UB? You can use restrict to get Fortran semantics.
  - bee_rider 5y ago
    Actually yeah, you are right. I somehow misread it as a defense of UB because of the last sentence. Total a brain-fart on my part, sorry.
aw1621107 5y ago
> in fact because of UB in C many forms of optimization are impossible in C because of aliasing uncertainty. This doesn't seem right? Specific types of aliasing make optimization more difficult/impossible because they are specifically not UB. Rust's aliasing optimizations can (theoretically?) occur specifically because same-type aliasing is UB in Rust. I'm not sure how "UB prevents optimization" falls out of that?

puffoflogic 5y ago

> If things are defined to not alias ... What do you call it then when you put aliasing pointers into pointer variables "defined not to alias"? Can you explain how this reduces UB?

foxfluff 5y ago
I think they're trying to say that if your language prevents aliasing (i.e. pointers by definition do not alias and it is impossible to make them alias), then the compiler doesn't need to worry about it. C doesn't prevent aliasing, therefore the compiler has to worry about every case of aliasing that isn't undefined. But it's not the UB here that prevents optimization, it's precisely the fact that aliasing is (sometimes) defined. If it were always UB, the compiler wouldn't ever have to worry about it... but that'd require some interesting changes to the language to keep it usable. Definitely not backwards compatible changes.
- puffoflogic 5y ago
- andrewla 5y ago
  > pointers by definition do not alias and it is impossible to make them alias This is equivalent to saying that pointer arithmetic is disallowed. Pointers are by their nature in the C virtual machine offsets into a linear memory space, so for any two pointers, x and y, there exists a c such that (ptr_t)x+c == (ptr_t)y, and thus there can always be aliasing.
  - gpderetta 5y ago
    Actually no, the C abstract machine is not contiguous. If x and y point inside distinct objects (recursively) not part of the same object, there is no valid c that you can add to x to reach y. edit: allowing that would prevent even basic optimizations like register allocation. edit: s/virtual/abstract/
    - andrewla 5y ago
      The C abstract machine requires reversible transformations from pointer to integral types (7.18.1.4 in C99, 3.3.4 in C90, the first ISO standard). Practically speaking modern devices are in fact mostly flat, so you can of course do this, although you do brush up against undefined behavior to get there.
      - wbl 5y ago
        Pointer provenance is more complex and subtle.
      - int_19h 5y ago
        Reversible transformations don't imply a flat address space. All it means is that there's an integral type with enough bits to record any address in them.
    - Shikadi 5y ago
      What is the c virtual machine? I thought there wasn't one
      - foxfluff 5y ago
        They mean the abstract machine, in terms of which the semantics are defined.
  - skissane 5y ago
    > Pointers are by their nature in the C virtual machine offsets into a linear memory space Historically, many platforms - such as Multics or Windows 3.x - didn’t have a linear memory space, they had some kind of memory segmentation. The industry has largely moved away from that towards the flat address space model. Go back to the 1980s, it was still a much bigger thing, and people used C on those platforms, and the standard was written to support them. The actual detailed control of memory segmentation is inherently non-portable so cannot be addressed by the standard, but the standard defines pointer arithmetic in such a way to support those platforms - pointer arithmetic on unrelated pointers is undefined, because if the pointers belong to different memory segments the results can be meaningless and useless.

bee_rider 5y ago

See also decades of Fortran performance dominance, only overcome by throwing a gazillion C programmers at the problem.

pjmlp 5y ago
In theory, because those gazillion C programmers happen to misuse restrict, so in the end it mostly ends up in flames.
gpderetta 5y ago
but doesn't Fortran get away with it exactly because argument aliasing is UB? You can use restrict to get Fortran semantics.
- bee_rider 5y ago
  Actually yeah, you are right. I somehow misread it as a defense of UB because of the last sentence. Total a brain-fart on my part, sorry.

aw1621107 5y ago

> in fact because of UB in C many forms of optimization are impossible in C because of aliasing uncertainty. This doesn't seem right? Specific types of aliasing make optimization more difficult/impossible because they are specifically not UB. Rust's aliasing optimizations can (theoretically?) occur specifically because same-type aliasing is UB in Rust. I'm not sure how "UB prevents optimization" falls out of that?