[fpc-devel] Question on updating FPC packages

[Florian Klämpfl]

Am 29.10.19 um 14:06 schrieb Marco van de Voort:
> 
> Op 2019-10-27 om 10:46 schreef Florian Klämpfl:
>> Am 27.10.19 um 10:27 schrieb Michael Van Canneyt:
>>> If you genuinely believe that micro-optimization changes can make a 
>>> difference:
>>>
>>> Submit patches. 
>>
>> As said: I am against applying them. Why? They clutter code and after 
>> all, they make assumptions about the current target which not might be 
>> always valid. And time testing them is much better spent in improving 
>> the compiler and then all code benefits. Another point: for example 
>> explicit inline increases normally code size (not always but often), 
>> so it is against the use of -Os. Applying inline manually on umpteen 
>> subroutines makes no sense. Better improve auto inlining.
> 
> Auto inlining is also no panacea.   It only works with heuristics, and 
> is thus only as good as a formula of the heuristic.

Yes. And manually adding inline is only as good as the knowledge of the 
user doing so. If somebody implements it right (I did not, I used the 
easiest approach and used an existing function to estimate the 
complexity of a subroutine). The compiler can just count the number of 
the generate instructions or even calculate the length of the procedure 
and then decide to keep the node tree for inlining.

> 
> Changing calling conventions, vectorizing, loops all complicates that, 
> and it will never be perfect, and a change here will lead to a problem 
> there etc.

See above.

> 
> If you know a routine can evaluate to one instruction in most cases, I 
> don't see anything wrong with just marking it as such.
> 

The compiler knows this as well as the compiler generated the code. Why 
should I guess if the compiler knows?