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?
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
