121–130 of 197 posts
A recent optimization in clang (not sure if it's in clang-9 or clang-10) will remove memsets to variables declared const, which usually come from assigning through a pointer that's had const (of the pointed to type) casted away. The MIPS Linux kernel won't boot when built with clang due to the above (I sent a patch 2 weeks ago)
Earlier quoted context omitted.
?? You say that it is only thing outside of the execution model that require volatile, but you explain that a signal handler requires volatile and to be the signal-atomic type. ;) In practice, volatile with lock-free types (that now stdatomic has a way to query whether types are lock-free) are correctly used all the time to pass data between threads. A volatile declaration may be used to describe an object correspond…
> You say that it is only thing outside of the execution model that require volatile No, I'm saying that the statement that volatile is only necessary and sufficient for outside the execution model. For signal handlers, it is necessary but not sufficient; for threads, it is neither necessary nor sufficient. > Or, from the C99 Rationale: C99 does not consider threading at all. C11 and C++11 do, and any compiler writte…
You seem to not be reading what I'm saying and also to be arguing with things I never asserted. e.g.
> Volatile is not sufficient to make double-checked locking safe.
OK, but I didn't say volatile makes double-checked locking safe... I said that the compiler's ability to reorder non-qualified variable accesses is "a big part of why" double-checked locking is an antipattern. My statement:
> Actually, you promise not to change things from another thread..., let alone a const! The compiler loads things into registers and has no way to know if memory in a passed reference changes underneath the hood... It can freely make optimizations that lead to incorrect computation, infinite loops, segmentation faults if this is not obeyed. If you've ever head about how "double check locking" is an antipattern, this is a big part of why.
The key difference between `const` and the `register` and `inline` keywords is that, despite all of them often flagging optimisations that the compiler can often work out anyway, `const` still aids human comprehension by declaring constraints, whereas the latter two do not. It seems that interprocedure optimisations in modern compilers make a lot of const-by-reference optimisations apply even when the code is mutable…
While specifying inline alone is useless for optimization, the inline specifier is important for another type of optimization: putting a function in a header file. If you put a function in a header file and don't mark it inline, that tends to be undefined behavior because it tends to violate the One Definition Rule, (both C and C++).
Ive usually encoutered this most when trying to implement out of line template member functions and forget to include the inline keyword.
const_cast risk is not why the compiler emits a reload. Indeed we don't even need to pass x to constFunc to get the reload: see line 7 in https://godbolt.org/z/TjmWxL Consider that `x` may point to a global variable which `something` may modify. That is why the reload is necessary. edit: I just realized that the reload would be necessary even without an intervening function call. https://godbolt.org/z/QhVzlV Consider…
> This is true in practice because enough real-world C code has “I know what I’m doing” casting away of const. I found this out the hard way when I implemented OptimumC, the first data flow analysis optimizer for DOS C compilers back in the 1980's. I had to undo doing optimizations on const. Anecdote: Optimum C blew away all the other C compilers on a magazine benchmark article because it figured out that the benchma…
Earlier quoted context omitted.
Yes, there are many cases where the caller can optimize the dependency chain / order of constFoo(x); constBar(x); where it couldn't make that assumption if one function wasn't const.
Unfortunately, C++ const functions are not necessarily pure functions and cannot be freely reordered.
> This is true in practice because enough real-world C code has “I know what I’m doing” casting away of const. I found this out the hard way when I implemented OptimumC, the first data flow analysis optimizer for DOS C compilers back in the 1980's. I had to undo doing optimizations on const. Anecdote: Optimum C blew away all the other C compilers on a magazine benchmark article because it figured out that the benchma…
>The author didn't ask me about it, he just assumed the compiler was buggy and gave us a bad review. Sigh. Did you write a letter complaining? Any response? Do you have a link to the review or copy of it? (Sorry, I just find this history fascinating).
BTW, it goes on. A couple years ago a kind soul gently suggested I implement DFA since clang had invented DFA.
(No, I didn't invent DFA either, but I do believe that Datalight Optimum C was the first DFA compiler for DOS.)
http://www.program-transformation.org/Transform/CCompilerHis...
The Data Flow Analysis code: https://github.com/DigitalMars/Compiler/blob/master/dm/src/d...
I've worked with JavaScript weenies who are in love with the const declaration. They don't have an answer, though, when I ask, "Shouldn't the compiler be able to notice that a variable isn't changed in it's lifetime?" Most of the const values are just local and never leave the function but the weenies continue to stomp their feet when I use "var". The compilers are smart. Let them do their thing.
> This is true in practice because enough real-world C code has “I know what I’m doing” casting away of const. I found this out the hard way when I implemented OptimumC, the first data flow analysis optimizer for DOS C compilers back in the 1980's. I had to undo doing optimizations on const. Anecdote: Optimum C blew away all the other C compilers on a magazine benchmark article because it figured out that the benchma…
Just as in the saying about how the best code is the code you didn't write, I guess the fastest benchmark is the one that doesn't run.
Earlier quoted context omitted.
If the initial object itself isn't const, then merely declaring the function parameter as a pointer to const won't guarantee that some other thread of execution won't change the value under your nose. Or if you have multiple pointer parameters, they can alias each other. Indirection in C and C++ is a mess, but at least C has the "restrict" keyword. Best to program with value types whenever you can, and use pointers a…
> won't guarantee that some other thread of execution won't change the value under your nose My understanding is that compilers can always assume that there is no other thread involved, which (part of) why C11 atomics are necessary. Is that not the case?
It is allowed to concurrently read from const regions. But not concurrently read and write, and definitely not concurrently write.