[fpc-devel] inline... and philosophy

[Florian Klämpfl]

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.