[fpc-devel] Optimisation and thread safety

Florian Klämpfl florian at freepascal.org
Sat Nov 13 11:54:35 CET 2021



> Am 13.11.2021 um 00:55 schrieb J. Gareth Moreton via fpc-devel <fpc-devel at lists.freepascal.org>:
> 
> Hi everyone,
> 
> I have a question when it comes to optimising memory reads and writes.  What are the rules for FPC when it comes to writing to memory and then reading from it later within a single subroutine? For example, say I had this pair of commands:
> 
>     movq    %rdx,-584(%rbp)
>     movl    -584(%rbp),%eax
> 
> That could easily be converted to "movl %edx,%eax", especially as %rbp is likely pointing to the top of the stack. 

This is not possible as rsp could be used as normal register.

If the reference is not marked as being read volatile, you can change the second mov into movl %edx,%ea.

For further optimizations you have to track tai_tempalloc which we don’t yet.

> But if the reference uses different registers, would it still be safe to make this optimisation given that the scheduler could suspend the thread in between the two instructions and then another thread writes to the same memory block before control is returned?
> 
> I am aware of other examples that require caution.  For example:
> 
>     movslq    -608(%rbp),%rdx
>     subl    %eax,-84(%rbp,%rdx,4)
>     movslq    -608(%rbp),%rdx
> 
> Here it might be tempting to remove the second "movslq" instruction, but the value of %rdx could happen to be equal to -131, which would allow the subl instruction to modify -608(%rbp), and in this situation, it's quite likely if a malicious input is given to the program to manipulate the value stored at -608(%rbp) and invoke a buffer overrun.

It could be also a pointer aliasing the memory location or an array, so this is not safe in any case. So something like a[a[1234]] which might be valid code imo.

> 
> So in conclusion, theoretically, where is it perfectly safe to assume the value in memory hasn't changed, where would it be permissible only under -O4 and where must it not be optimised at all?
> 
> Gareth aka. Kit
> 
> P.S. Assembly examples were taken from the System unit.
> 
> 
> -- 
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



More information about the fpc-devel mailing list