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@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

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to