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

[J. Gareth Moreton]

I'd say the people have spoken.  No "safe"!  Don't worry, I'm not going 
to get angry or anything... I'm appreciating the discussion we're having.

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;"

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.  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).

Maybe it already works this way, but I would like to see -O4 work under 
all general-purpose circumstances where code doesn't use any 
implementation-specific practices like trying to access a field by a 
hard-coded pointer offset or using an unsafe or questionable typecast 
(e.g. typecasting a pointer to a LongInt as a PWord) that would trick 
most compiler checks.

If a volatile attribute existed for variables, then the compiler could 
throw a warning if you pass it into a routine's var parameter.  If 
there's no upper limit on how long -O4 would take to compile, then the 
compiler can do things like keep track on what volatile variables a 
procedure accesses and be more selective in when such a warning is thrown.

Originally, the "safe" proposal was so I didn't have to flood the code 
with manual instances of promoting global variables into local 
registers.  To quote my original example - 
https://bugs.freepascal.org/view.php?id=35479 - I promote the domain's 
lower and upper bounds to object fields so one doesn't have to call 
"getrange" more than once (it makes a notable saving).  At the same 
time, I only write to the fields once the code has finished using them 
in expressions (setting "jumptable_no_range").  Then in the actual jump 
table creation routine, it reads those fields into local variables so 
there's no longer a need to perform constant pointer dereferences.  It's 
a subtle speed-up that is largely overshadowed by the removal of 
"getrange", but doing this too much risks the code becoming an unwieldly 
mess, as well as cases of flawed programmer logic when they copy a 
global variable to a local one, but then it's only read once.  I suppose 
the answer to that one is to make sure the "volatile" 
intrinsic/attribute is well-documented, especially mentioning it if such 
optimisations become part of -O4, say.

Gareth aka. Kit


On 05/05/2019 14:38, Jonas Maebe wrote:
> On 05/05/2019 15:31, Marģers . via fpc-devel wrote:
>>> As mentioned in a previous message, fpc trunk
>> supports a volatile
>>> intrinsic:
>>>
>> http://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_.22volatile.22_intrinsic 
>>
>>
>> My bad, I didn't know about volatile intrinsic.
>> So, does it mean that compiler is allowed to
>> optimize any variable, even promote global
>> variables to registers, as long they are not in
>> volatile(...)?
>
> The compiler would also need to prove that no writes can happen 
> through aliases for the duration that they are kept in registers. It 
> has no support for this yet.
>
> LLVM does have support for this though, and does perform such 
> optimisations on code generated by FPC via the LLVM backend.
>
>
> 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