[fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

[Sven Barth]

Am 28.10.2018 um 13:00 schrieb Simon Kissel:
>
>> Additionally, in the current FPC code generator global variables behave
>> mostly as volatile variables. With LLVM, that won't be the case (unless
>> we mark all of their accesses as volatile, but that would obviously
>> inhibit LLVM optimizations). This may break some multithreaded code that
>> currently works, and would probably require the introduction of a
>> volatile() operatator (similar to the unaligned() one). On the other
>> hand, I already added support for tracking the volatile state of
>> references in the past, so that should be easy to do.
> I have to admit my knowledge on this is very limited. We do
> use global variables unsynchronized in Multi-Threaded code,
> but only in a single-writer multiple-reader scenarios, in these
> cases we don't have any expectations for the new value to be
> available "immediately". Obviously the compiler can not know at
> what point during runtime the thread gets scheduled, but what
> are the rules (if any) on "how long" it takes for a volatile
> variables content to get "flushed"? Is there some scoping involved
> like "on return of current function/method"?
What volatile means in this context is that the compiler always fetches 
the global value anew when it is accessed instead of e.g. caching it in 
a register which could be done if global variables would not be 
considered as volatile.
> Unlike the crap that Embarcadero has been polluting the language
> with in recent years, I think that adding support for volatile()
> to the language would make a lot of sense - however potentially
> turning this around so that the unmodified default stays
> volatile, and an implementing an erm.. "non-volatile" modifier
> instead, so not to break existing code.
It seems that Delphi changed the default behavior in their NextGen 
compiler (probably due to the same reasons that Jonas stated for LLVM) 
as they introduced a "[volatile]" compiler attribute to decorate global 
variables and fields so that the compiler handles them as volatile...

Regards,
Sven