Yes, that's why I said "...whose result depends on nothing but its arguments." - the example bar() function in the original article does not read global memory, so it can be declared __attribute__((const)).
Sure. I was just pointing out that that is a stricter constraint than required for the optimization in question. Doing loop hoisting and CSE wants "pure" functions, because pure "means" a function without side effects.
The "meaning" of const is that the function depends on nothing but its arguments, and can therefore have its value computed at compile time, or be part of a global CSE pass. That's a different optimization.
It seems to me that loop hoisting would also be easier with ((const)), because to do so with a ((pure)) function requires further assessing that the loop does not modify any global state that might be visible to the ((pure)) function. A ((const)) function can be hoisted out of a loop even if the loop modifies globals, or values through pointers that might point at globals.
The "meaning" of const is that the function depends on nothing but its arguments, and can therefore have its value computed at compile time, or be part of a global CSE pass. That's a different optimization.