[fpc-devel] inline... and philosophy

[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 
around, so the label is actually dead when StripLabelFast is called.  It 
won't affect the output in any way, but will hopefully reduce the risk 
of alarming another programmer who stumbles upon it.

Gareth aka. Kit


On 10/11/2019 16:45, Florian Klämpfl wrote:
> Am 10.11.19 um 17:42 schrieb J. Gareth Moreton:
>>
>> Some of the "condition_in" functions need expanding though, and I 
>> don't yet have an answer if it's okay to do operator overloading in 
>> the compiler source (so I can do things like "if (jmp1.cond in 
>> jmp2.cond) then", for example, instead of the more ambiguous "if 
>> condition_in(jmp1.cond, jmp2.cond) then".
>
> I wouldn't do, for somebody without experience with the code, this is 
> confusing. Operator overloading makes imo only sense if it effects a 
> lot of code and makes it more readable because it replaces a lot of 
> nested function calls.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>