Am 10.11.19 um 18:01 schrieb J. Gareth Moreton:
Fair enough - thank you.
This is a bit of a micro-optimisation for the compiler in regards to
what I've just done, but I've noticed that, a couple of times, commands
to the effect of the following appear:
tasmlabel(symbol).decrefs;
if tasmlabel(symbol).getrefs = 0 then
...
That is... dereference a label, and then do something if it turns into a
dead label (usually remove it). Would it be permissible to change the
decrefs method so it returns a Boolean expression, namely True if the
reference falls to zero and False otherwise? Given the function already
checks to see if the reference count is less than zero (to raise an
internal error), it should have negligable performance loss, and if
anything, the new jump optimisations will help a lot.
In the meantime, I've just taken a quick look at my code, and noticed
something possibly a little risky (compiler/x86/aoptx86.pas, line 3540):
{ Remove label xxx (it will have a ref of zero due to the initial check }
StripLabelFast(hp4);
{ Now we can safely decrement it }
tasmlabel(symbol).decrefs; >
There's nothing actually buggy with the code because it's known that the
label has a reference count of 1 at this point, but "StripLabelFast"
removes the label while it's still live, something that I even said in
the procedure's comments that you shouldn't do! i.e. I broke my own
rule! To be safe, these two commands should probably be switched
Committed.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
