[fpc-devel] Possible idea... "safe" subroutines/methods

[J. Gareth Moreton]

Thanks so much for the insight Jonas.  Heh, Linus is as passionate as I 
am sometimes... volatile is evil and all!  It makes sense though... and 
it will encourage people to write better code.

The 'spinning on a global variable' I admit I've used.  In my case it 
was in a slave thread that did some number crunching in a long loop, and 
if the main program wanted to close, it would set the "Terminate" flag, 
which would make the loop exit and do some clean-up before the slave 
thread wraps up.  My concern was that checking an 
implementation-specific semaphore would be prohibitively inefficient in 
a tight loop.

I think as long as "volatile" is well-documented, especially on topics 
of multi-threaded code, then everything should be fine.

To use the compiler again as an example, once place where I can see 
advantages of moving values to local registers is with the "TmpUsedRegs" 
field, which is a pooled object that is created when the optimiser 
object is instantiated, and is used by the peephole optimiser when it 
wishes to look ahead with register usage (originally, TmpUsedRegs was 
created and destoyed if and when it was needed, but I argued to make it 
a pooled object in order to remove excess allocation and deallocation, 
and also improved maintenance because a couple of the methods forgot to 
free TmpUsedRegs afterwards, causing a memory leak).  The internal 
pointer never changes, and all the var parameters of functions like 
OptPass1MOV contain an incompatible class, so unless you do something 
crazy with typecasting, moving TmpUsedRegs to a local register or stack 
value can only provide a speed gain (and if you do crazy thing with 
typecasting, you're likely to case an access violation anyway).

So if I was to start researching the promotion of global values into 
local registers or, at the very least, the stack, should it still be an 
-O4 option, or is it safe enough to promote to -O3, so long as things 
like var parameters are carefully checked?  For the deepest of 
optimisations, it might get slow, but is this acceptable for -O3 and -O4?

Gareth aka. Kit

On 05/05/2019 19:35, Jonas Maebe wrote:
> On 05/05/2019 19:34, J. Gareth Moreton wrote:
>
>> For the volatile intrinsic, was there talk of "volatile" being an 
>> attribute as well? I'm guessing this means declaring something as, 
>> for example "var FTerminated: Boolean volatile;"
>
> See 
> http://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_.22volatile.22_intrinsic 
> and the linked article from that entry for more about that.
>
>> My fear with allowing the promotion of global variables to registers 
>> is that it will break old code written when the "volatile" intrinsic 
>> didn't exist.
>
> There is very little thread-safe code that can be broken by this 
> change. The reason is that just waiting on a global variable to change 
> its value is not nearly enough to synchronise two threads, unless they 
> don't exchange any other data besides that one single variable. You 
> need memory barriers and on certain architectures also 
> acquire/release, all of which cannot be analysed by the compiler and 
> hence it will have to assume that all global data may have changed 
> across them (and hence it will reload all global data from memory).
>
> Additionally, spinning on a volatile variable (without calling "yield" 
> or something similar in the loop, which would stop this change from 
> breaking anything) is about the most inefficient way in existence to 
> synchronise two threads.
>
>>   Then again, it can simply be an option that is only present in -O4 
>> or if the programmer specifically asks for it (and maybe as an option 
>> in Lazarus' "Project Options" dialog).
>
> That is not possible for LLVM at least. It's just a generic 
> optimisation there. I don't consider this to be a big problem, because 
> proper multi-threading code won't be affected by it. Broken code will 
> also break in a very obvious and easy to locate way: it will just sit 
> in an endless loop at the location where the loop was.
>
>
> Jonas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus