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

[J. Gareth Moreton]

This is why I posted to the group!  You can catch things that I might miss.

For the aliasing issue, I envisioned that var parameters wouldn't be 
affected.  Since the address is already in a register or on the stack, 
it's relatively efficient already.

For the subroutine call, that is indeed a little more difficult, and the 
compiler would have to consider that a subroutine call may modify one of 
the non-local values.

C/C++ was never my first language, so generally I try not to mirror it.  
I even joked that seeing C-style standards in Pascal source is 
tantamount to colonialism!

I've noticed that my take on coding is somewhat different to others at 
times.  I tend not to trust the compiler to make the most efficient 
code.  I think the best analogy would be the difference between the 
Quake and the Unreal engines... Quake does all the BSP and portal 
building itself during a map compilation stage, while with the Unreal 
engine, the mapper decides where portals and the like go.  It is a tiny 
bit more work, but it allowed for highly detailed and optimised maps so 
long as you used a bit of logical thinking.

The reason why I suggested a modifier directive is for similar reasons 
why I'm doing the same thing with pure functions... for compilation 
speed.  If a function is marked as pure, the compiler will have to do a 
lot more processing and analysis, so if all functions are implicitly 
considered pure until proven otherwise, it will slow down compilation 
significantly.  A similar thing may happen with safe functions because 
it will have to undertake data flow analysis.  It's hard to say if the 
compiler performance hit will be significant or not, but you may be 
right in that safe procedures can be merged with data-flow analysis if 
it becomes a major part of the compiler.  The only risk is with 
multi-threading again - if a procedure suddenly behaves differently 
under the highest optimisation settings because of the lack of a 
'volatile' intrinsic, I personally consider it a bug (which is why I'm 
not a fan of -O4 with its advertised 'may cause side-effects').

It does make for some interesting discussion though!

Gareth aka. Kit


On 04/05/2019 09:37, Jonas Maebe wrote:
> On 2019-05-03 19:37, J. Gareth Moreton wrote:
>> By telling the compiler that the procedure (or maybe a whole class) is
>> thread-safe, you are telling it that you can guarantee that any
>> objects, fields or global variables that you access are guaranteed to
>> not suddenly change mid-routine (because another thread has modified
>> it).  This would allow the compiler to move commonly-accessed fields
>> into local registers or the stack for faster access, especially if the
>> fields are only read and not written, since they'll be guaranteed to
>> contain a constant value.
>
> Multi-threading is not the main issue. The main problems are aliasing 
> and subroutine calls:
>
> 1) Aliasing
>
> type
>   tc = class
>     a: longint;
>     procedure test(var l: longint);
>   end;
>
> procedure tc.test(var l: longint);
> begin
>   if a<>5 then
>     begin
>       l:=1;
>       // the above will change c.a to 1, but if c.a is in a register 
> that will not be detected
>       if a<>1 then
>         writeln('error');
>     end;
> end;
>
> var
>   c: tc;
> begin
>   c:=tc.create;
>   c.a:=6;
>   c.test(c.a);
>   c.free;
> end.
>
>
> 2) subroutine calls
>
> type
>   tc = class
>     a: longint;
>     procedure test;
>   end;
>
> var
>   c: tc;
>
> procedure change;
> begin
>   c.a:=1;
> end;
>
> procedure tc.test;
> begin
>   if a<>5 then
>     begin
>       change;
>       if a<>1 then
>         writeln('error');
>     end;
> end;
>
> begin
>   c:=tc.create;
>   c.a:=6;
>   c.test;
>   c.free;
> end.
>
> In both cases, many additional scenarios are possible (there are many 
> different way to alias memory and to perform modifications in 
> subroutine calls).
>
> For the former, you need inter-procedural alias analysis, or limit 
> yourself to routines that only write to local variables. For the 
> latter, you need to limit yourself to routines that don't call other 
> routines, and/or record various function attributes that indicate what 
> these other routines do. See e.g. the function attributes from LLVM 
> (http://llvm.org/docs/LangRef.html#function-attributes) like 
> inaccessiblememonly, inaccessiblemem_or_argmemonly, readnone, 
> readonly, writeonly, and argmemonly. Since LLVM found a use for them 
> in terms of optimising code, they're probably a good a start.
>
> I wish to stress that I do _not_ propose or support adding any of 
> those attributes to the language; most of those attributes don't exist 
> in C/C++ either. They get added by LLVM itself while optmising and 
> analysing the functions, or by compiler backends for auto-generted 
> functions.
>
> However, you could add compiler analyses that add those, or similar, 
> attributes to the implementation procdef flags 
> (tprocdef.implprocoptions), and then make use of those attributes even 
> in cross-unit calls (in case the body of the function in the other 
> unit has already been compiled, similar to inlining). Or in case of 
> whole-program optimisation, they could written and loaded for the 
> entire program, so you can use them even when function bodies have not 
> yet been parsed.
>
> As far as the threading issue is concerned: trunk has support for the 
> "volatile" intrinsic. At most, I would add an optimizer option that 
> prevents optimisations that may break things in case "volatile" is 
> missing. This should happen in very few places though, since it can 
> only change the behaviour of a well-defined program if you are 
> busy-waiting on a single value that another thread may change (and do 
> nothing else with values produced by this other thread, unless you 
> also add a bunch of memory barriers and, depending on the 
> architecture, also acquire/release helpers).
>
>
> 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