[fpc-devel] Const optimization is a serious bug

[Martin]

On 07/07/2011 18:29, Alexander Klenin wrote:
>
>> But no compiler can identify every occurrence where the ref count can be
>> ommitted.
>>
>> so it still stands:
>> What you want, is the removal of a feature from pascal. The feature for the
>> programmer to explicitly skip the ref count (at the programmers own risk)
> Well, don't you think that "expliciitly ask to skip refcount" feature
> is quite different from "constant parameter"?
Not necessarily:

if const reads: I (the programmer) tell the compiler this value is going 
to be constant
versus: I ask the compiler to help me avoid changing it

But as in my other mail, it may not be best named (but now we are 
changing topic, it's not about the feature anymore, it's about the name)

At first sight (and first sight only) I would say, if it wasn't yet 
there and a name was to be choosen, I'd choose another name.

But at 2nd sight, I retuned to the example with the caching of expresion 
results.. And If the feature would really mean const "the value of this 
variable will not change, not from within nor from outside this 
function" (and that is what in case of a record (passed by ref) is 
needed to be real const, and allow all the optimization.
Now if I declare const should actually mean that, I am back to where we 
are no. Only stricter...

in c++ you can mark an entire method to be const. Means that method can 
not call any thing, that modifies the object.
If I wanted to go all the way in pascal, then "const x: type" should mean:
- the compiler allows no modification of x in the procedure (exists in fpc)
- the compiler allows x only as param, if the param is const too (exists 
in fpc)
- (new) the compiler prevents calling any other code (any method, 
procedure, or event) unless it has proven knowlege that this code does 
not do anything that could modify the value of x
   eg only calls to methods that do not modify any variable of the type 
of x at all (and that do not call anything that does...)


> At some stage, semantic annotation got conflated with a specific
> optimization it allowed.
> I propose to decouple them -- let the "const" mean "constant"
> (which, by the way, can not be achieved currently, so it would be new feature),
> and do refcount skipping only if safe
> (or, for the really critical codepaths, introduce a separate,
> explicitly-named annotation,
> something like "const norefcount").
If it was anew feature...


>> If that is the case: Should we remove "move" / "fillchar" too? Because they
>> can do the same.
> There is Move and there is assignment.
> You would not advocate always perform "Move" on assignment,
> beause it is slightly faster, even if it breaks some code like
> AnsiString assignment?
>
"advocate"

Neither do I advocate  to use const, unless you know what you do..... 
And if anyone advocates it, then it's a problem (but not a problem of 
the feature)