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

[Simon Kissel]

Hi Jonas,

>> - Complete the LLVM branch of FPC. It looks like Jonas has stopped
>>    working on it two years ago, which is a pity.

> I didn't stop working on it, but I didn't make real progress anymore 
> either.

So, would you be interested in making progress again? :)

> a) exception handling in general: indeed needs DWARF-EH support in the
> RTL, and also support for the LLVM exception handling intrinsics in the
> code generator. I've worked on and off on this and have some local 
> patches, but it's not complete

So maybe someone else could work on DWARF exceptions, which then
would enable you to progress on LLVM?

> have been working a bit on it since then). This is not something that
> can be changed/fixed in FPC, and is quite different from how FPC's 
> current code generator works (I don't know how Embarcardero deals with
> it in their LLVM-based code generator).

Someone could do some reverse engineering to learn more
about how they have solved the problem (unlike actually copying
code I don't see any legal or ethical problem in learning from
reversing).

If the lone Embarcardero russian Java-developer-turned-compiler
engineer can do it, you guys sure can, too ;)

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

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.

Cheers,

Simon