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

Hi Florian, > Do you compile with -Aas? The internal assemblers do not support TLS yet, > this is WIP. Ah wow! -Aas does indeed help. Both the assembler errors and the internal error are gone, both in Linux i386 and ARM. And the created binaries even work. Nice! Thank you! Cheers, Simon

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

Am 04.12.2018 um 02:16 schrieb Simon Kissel: > Hi Florian, > > > > we are currently to try to do some real-life benchmarks with our > products, however with rev. 40346 compilation fails with the two following > showstoppers: Do you compile with -Aas? The internal assemblers do not support TLS

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

Hi Florian, we are currently to try to do some real-life benchmarks with our products, however with rev. 40346 compilation fails with the two following showstoppers: 1.) The assembler parser appears to be broken - the following very valid opcodes get rejected: SBMath.pas(1932,9) Error: Asm:

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

Hi guys, that platform is not relevant for us, but to provide some motivational boost: CrossFPC 4.14 beta Win64: C:\Users\BeRo\Documents\Projects\Tests\threadingtest0\aa>vipribenchmemcache_nodeps VipriBenchThreaded - RunningTimeSeconds=5, TestCount=100, StartSeq=0, NumberOfChannels=6,

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

On 27/10/18 18:21, Ben Grasset wrote: LLC (at least now) statically links the necessary parts of LLVM and works independently of Opt, with a simpler set of command line options (it just has overall O1, O2, and O3 flags.) Are you certain llc now incorporates the functionality of opt? From what

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

Am 23.11.2018 um 21:07 schrieb Simon Kissel: > problem is distributed all across the code. However, there > is something sticking out, being at the very top of pretty > much all multi-threaded code we compile: > > fpc_pushexceptaddr & CRelocateThreadVar. > This, however, does the benchmark not

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

On Sat, November 24, 2018 13:43, Adriaan van Os wrote: > Simon Kissel wrote: Hello all, > In case you are just trolling, I recommend reading > a book on programming, learning to write better code. Could we stop this, please? This is neither on topic, nor very polite, especially after Simon

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

Simon Kissel wrote: Hi Adriaan, In case you aren't just trolling and the subject really is of interest to you, I would recommend reading the discussion thread in full. That works much better than treating this like a write-only system. In case you are just trolling, I recommend reading a book

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

Am 23.11.2018 um 21:07 schrieb Simon Kissel: > own code, it won't get much better than what it is today, > and that Kylix producing faster code does not compensate it Well, to be fair, there is a lot of code out there where FPC is faster. Nevertheless, FPC's code can be still improved.

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

Hi Adriaan, In case you aren't just trolling and the subject really is of interest to you, I would recommend reading the discussion thread in full. That works much better than treating this like a write-only system. > You didn't answer any of my questions. The goal is to get the > code faster,

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

Hi Florian, > Actually, most of the improvements so far are no related to > threading. In particular r40339 helped a lot, it was a bug > fix: the compiler assumed that a certain sub expression was written > while it not was and this prevented CSE. Even better, that means there is still gold to

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

Am 23.11.2018 um 14:36 schrieb Simon Kissel: > Hi Adriaan, > >> I find the phrase. "FPC's terrible multi-threading performance" >> unjust. > > Well, see the complete thread to better understand what this > is about, and what progress is being made. So far a 20% > improvement has been made, which

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

Simon Kissel wrote: This isn't about FPC's code not scaling with N cores, it does. It is about it being slow as soon as threads are used *at all*, N cores being near N times faster than "not using threads at all". due to TLS stuff and exception handling. It's slow in a linear fashion, so to

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

Hi Adriaan, > I find the phrase. "FPC's terrible multi-threading performance" > unjust. Well, see the complete thread to better understand what this is about, and what progress is being made. So far a 20% improvement has been made, which kinda is like a proof that there was something to improve

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

Am Fr., 23. Nov. 2018, 12:15 hat Adriaan van Os geschrieben: > Simon Kissel wrote: > > > We know about a couple of bottlenecks (fpc_pushexceptaddr / > > RelocateThreadVar etc) which explain FPC's terrible multi-threading > > performance, but in general, FPC's code generator really is quite > > a

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

Simon Kissel wrote: We know about a couple of bottlenecks (fpc_pushexceptaddr / RelocateThreadVar etc) which explain FPC's terrible multi-threading performance, but in general, FPC's code generator really is quite a mess, which we learned the hard way a couple of years when we did optimization

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

Hi Florian, > The changes help also on arm and arm can be build using the same > command line, however, at least on a Raspi3B+ the > improvement is less significant than on i386 (still the old cache > flush (?) issue which is outside of the scope of FPC?). Actually the changes are significant:

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

Hi Florian, > Compile the benchmark with (where fpcnew is the newly build fpc): Bero has confirmed, works for us as well. This rocks! > The changes help also on arm and arm can be build using the same > command line, however, at least on a Raspi3B+ the > improvement is less significant than on

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

Am 17.11.2018 um 22:28 schrieb Florian Klämpfl: > Am 17.11.2018 um 22:10 schrieb Simon Kissel: >> Hi Florian, >> >>> With some compiler tuning and a few tricks (two changes to the code >>> and hand-simulated peephole optimizations, but I >>> think these tricks can also the compiler do): >> >> Nice

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

On 17/11/18 22:15, Simon Kissel wrote: How far of a way is that? Sadly we'll have to support some 32 bit platforms for a couple more years... I really don't know. It's not something I have looked into, but I'm afraid it will be messy. And how far away is getting this to run on Linux?

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

Am 17.11.2018 um 22:10 schrieb Simon Kissel: > Hi Florian, > >> With some compiler tuning and a few tricks (two changes to the code >> and hand-simulated peephole optimizations, but I >> think these tricks can also the compiler do): > > Nice - what changes did you do? > > Changing the code of

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

Hi Jonas, Nice results! > Since I only have a preliminary llvm version (with Dwarf EH) running on > macOS, I can't provide a direct Kylix comparison. The versions below are > both x86-64. As mentioned before, a 32 bit FPC/LLVM is still quite a way > off. How far of a way is that? Sadly we'll

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

Hi Florian, > With some compiler tuning and a few tricks (two changes to the code > and hand-simulated peephole optimizations, but I > think these tricks can also the compiler do): Nice - what changes did you do? Changing the code of course is cheating, but there might be something to learn for

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

On 16/11/18 23:41, Florian Klämpfl wrote: diff --git a/compiler/nmem.pas b/compiler/nmem.pas index d5c1d85e8f..52add1fd81 100644 --- a/compiler/nmem.pas +++ b/compiler/nmem.pas @@ -1176,7 +1176,7 @@ implementation begin include(flags,nf_write); { see comment in

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

Am 16.11.2018 um 23:41 schrieb Florian Klämpfl: > Am 16.11.2018 um 23:36 schrieb Jonas Maebe: >> On 16/11/18 22:44, Florian Klämpfl wrote: >>> With some compiler tuning and a few tricks (two changes to the code and >>> hand-simulated peephole optimizations, but I >>> think these tricks can also

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

Am 16.11.2018 um 23:36 schrieb Jonas Maebe: > On 16/11/18 22:44, Florian Klämpfl wrote: >> With some compiler tuning and a few tricks (two changes to the code and >> hand-simulated peephole optimizations, but I >> think these tricks can also the compiler do): > > You can improve performance

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

On 16/11/18 22:44, Florian Klämpfl wrote: With some compiler tuning and a few tricks (two changes to the code and hand-simulated peephole optimizations, but I think these tricks can also the compiler do): You can improve performance further by devirtualising all method calls using wpo. First

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

Am 16.11.2018 um 20:22 schrieb Simon Kissel: > Hi guys, > > turns out that in our real-life scenario there sadly aren't big > improvements yet. Might be due to the exception handling, but > we haven't profiled it yet. As said we have seen better improvements > in simpler benchmark code - but this

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

Hi guys, turns out that in our real-life scenario there sadly aren't big improvements yet. Might be due to the exception handling, but we haven't profiled it yet. As said we have seen better improvements in simpler benchmark code - but this benchmark here is what really matters for us. Please

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

Am 14.11.2018 um 14:46 schrieb Simon Kissel: > > We have not yet tested this on ARM (does it work on ARM?). > After r40321, arm-linux works as well. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

Am Mi., 14. Nov. 2018, 14:46 hat Simon Kissel < simon.kis...@nerdherrschaft.com> geschrieben: > Hi Florian, > > you are a hero. In a very artificial benchmark which just consists > of threads and exception handlers, a 32 bit Linux executable now > is *twice as fast*! > Up to now only thread

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

Hi Florian, you are a hero. In a very artificial benchmark which just consists of threads and exception handlers, a 32 bit Linux executable now is *twice as fast*! In a real-life scenario we are "only" seeing an improvement of about 10%. But really, this is huge progress. I think everyone will

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

Am 07.11.2018 um 23:00 schrieb Florian Klämpfl: > - threadvars in FPC built libraries do not work yet This is fixed with r40281. It requires though that all units being part of a library are compiled with -fPIC. Now waiting for Simon, if he reports any improvements ...

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

Am 25.10.2018 um 20:13 schrieb Florian Klämpfl: In case somebody wonders: as I started years ago on tls-based threadvars, I decided first to work on this one first and try to bring this code into a commitable state. ___ fpc-devel maillist -

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

On 28/10/18 13:00, Simon Kissel wrote: Hi Jonas, [exceptions for invalid memory accesses] 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

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

On 28/10/18 19:14, Jonas Maebe wrote: I've committed it in the dwarf_eh branch. Unfortunately, the an x86-64 compiler compiled with optimizations enabled crashes while compiling this code (probably due to https://bugs.freepascal.org/view.php?id=34385 :) ) Actually, it was to a bug in my

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

On 25/10/18 21:33, Sven Barth via fpc-devel wrote: As you already started working on translating that part of libgcc, would you please provide what you have so far? :) I've committed it in the dwarf_eh branch. Unfortunately, the an x86-64 compiler compiled with optimizations enabled crashes

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

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

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

Hi Florian, [DWARF-EH] > This is something I would like to work for years on already. So > maybe its now a good opportunity to start with it. *hugs* Simon ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

Hi Sven, > Borland's Fastcall is more famously known as the Register calling > convention aka the default calling convention in Object Pascal. As > you admitted in your mail further down you have quite some assembly > code and as such you rely on the calling convention for parameter > passing.

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

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

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

Simon Kissel schrieb am So., 28. Okt. 2018, 12:46: > Hi Florian, > > > But there is another pretty simple optimization opportunity in this > > area: make the FPC heap manager capable of using > > os-based memory reallocation. Kernel-based memory reallocation of > > large blocks has the big

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

Simon Kissel schrieb am So., 28. Okt. 2018, 12:39: > Hi Ben, > > > There's one more problem I forgot to mention in my first post, and it is > > probably a deal breaker for the original bounty: LLVM does not support > > Borland's fastcall calling convention for i386. So you would need to add >

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

Hi Sven, > The thing is that we can't enable or disable a feature based on > whether a program links third party libraries or a unit is included > in a library or not, cause we might need to work with precompiled > units. So either you'll need to enable this feature for a locally > build FPC amd

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

Hi Florian, > But there is another pretty simple optimization opportunity in this > area: make the FPC heap manager capable of using > os-based memory reallocation. Kernel-based memory reallocation of > large blocks has the big advantage that the OS can > move the memory contents only by

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

Simon Kissel schrieb am So., 28. Okt. 2018, 12:30: > Hi Florian, > > > The %gs based approach works only for object files linked statically to > > the executable. In general there are four TLS access models on linux and > > at least three of them need to be supported, if one wants to support > >

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

Hi Sven, > And no one said that it is. But points like table based exception > handling and section based threadvars can be relatively easily > achieved and benefits more targets while working on the optimizer > usually is a per platform work. I agree that this very likely will make a big boost.

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

Hi Ben, > There's one more problem I forgot to mention in my first post, and it is > probably a deal breaker for the original bounty: LLVM does not support > Borland's fastcall calling convention for i386. So you would need to add > support for Borland fastcall on i386 to LLVM if it has to

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

Hi Florian, > The %gs based approach works only for object files linked statically to > the executable. In general there are four TLS access models on linux and > at least three of them need to be supported, if one wants to support > dyn. libraries in a usefull manner. Are you talking about

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

Am 28.10.2018 um 02:11 schrieb Ben Grasset: > > There's also a number of things that would specifically help the build-time > performance of the compiler itself that I've > noticed, such as there being many, many, many, one-liner functions and > procedures that should almost certainly be marked

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

Am 28.10.2018 um 02:24 schrieb Ben Grasset: > On Sat, Oct 27, 2018 at 8:22 PM Ozz Nixon > wrote: > > * Sorry for off topic - just that grabbed my "What did he just say?" > button.. > > > Huh? I said "Also linked lists absolutely everywhere, that would perform

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

On Sat, Oct 27, 2018 at 8:22 PM Ozz Nixon wrote: > * Sorry for off topic - just that grabbed my "What did he just say?" > button.. > Huh? I said "Also linked lists absolutely everywhere, that would perform much better as array based lists." Meaning, exactly the same thing you just implied. You

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

SORRY - JUST RE-READ... that is what you are saying... it's late here ;-( On Sat, Oct 27, 2018 at 8:22 PM Ozz Nixon wrote: > * Not arguing, but... * > > Linked List faster than Array? > Unless I missed what you are talking about... I always teach programmers: > > Array is the fastest collection

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

* Not arguing, but... * Linked List faster than Array? Unless I missed what you are talking about... I always teach programmers: Array is the fastest collection to use, followed by Linked List, followed by bTree, etc. * Sorry for off topic - just that grabbed my "What did he just say?"

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

On Sat, Oct 27, 2018 at 6:46 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Except of course for optimizations that can be done on the platform > independent node tree. > That specifically is IMO the "key" to a higher compiler-wide level of optimization capabilities, as

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

Ben Grasset schrieb am So., 28. Okt. 2018, 00:29: > On Sat, Oct 27, 2018 at 1:38 PM Florian Klämpfl > wrote: > >> That it is useful to work on table based exception handling for all >> targets >> > > Not arguing with that at all. I was just trying to point out that I'm not > a fan of the idea

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

On Sat, Oct 27, 2018 at 1:38 PM Florian Klämpfl wrote: > That it is useful to work on table based exception handling for all targets > Not arguing with that at all. I was just trying to point out that I'm not a fan of the idea that FPC's code generators are "good enough" as is.

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

Am 27.10.2018 um 19:19 schrieb Michael Van Canneyt: > > > On Sat, 27 Oct 2018, Florian Klämpfl wrote: > >> If you read the whole thread, LLVM needs a rewritten exception handling as >> well. Further, a quick test >> of table based exception handling on bansi1 (which is mainly a memory >>

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

Am 27.10.2018 um 18:21 schrieb Ben Grasset: > On Sat, Oct 27, 2018 at 8:47 AM Jonas Maebe > wrote: > > On 27/10/18 05:45, Ben Grasset wrote: > >    > > You also need "opt" if you want to perform full optimizations (or just > use clang, which a.o.

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

On Sat, Oct 27, 2018 at 8:47 AM Jonas Maebe wrote: > On 27/10/18 05:45, Ben Grasset wrote: > You also need "opt" if you want to perform full optimizations (or just > use clang, which a.o. combines the functionality of llc and opt). > > There's one more problem I forgot to mention in my first

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

On 27/10/18 05:45, Ben Grasset wrote: As far as dependencies, it would add none whatsoever other than a copy of the LLC or LLVM-AS binaries (as in, no more than any other target FPC supports. Just think of it as yet another assembler format.) You also need "opt" if you want to perform full

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

On Saturday 27 October 2018 09:27:59 Sven Barth via fpc-devel wrote: > > > > Not really. The IR format has been pretty stable since version 3.9 or so > > (LLVM is current at version 8.) As far as dependencies, it would add none > > whatsoever other than a copy of the LLC or LLVM-AS binaries (as

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

Ben Grasset schrieb am Sa., 27. Okt. 2018, 05:46: > On Thu, Oct 25, 2018 at 3:06 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Simon Kissel schrieb am Do., 25. Okt. >> 2018, 08:54: >> >>> - Complete the LLVM branch of FPC. It looks like Jonas has stopped >>>

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

On Thu, Oct 25, 2018 at 3:06 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Simon Kissel schrieb am Do., 25. Okt. > 2018, 08:54: > >> - Complete the LLVM branch of FPC. It looks like Jonas has stopped >> working on it two years ago, which is a pity. >> > > I personally

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

Am 25.10.2018 um 20:34 schrieb Jonas Maebe: On 25/10/18 20:13, Florian Klämpfl wrote: Am 25.10.2018 um 18:59 schrieb Jonas Maebe: On 20/10/18 16:07, Simon Kissel wrote: - Complete the LLVM branch of FPC. It looks like Jonas has stopped     working on it two years ago, which is a pity. I

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

On 10/20/18 4:07 PM, Simon Kissel wrote: The requirements for my bounty would be: - Must bring executable speed for non-Floating point load on both multihreaded and non-multithreaded workloads to the Speed of Kylix combined binaries - Improvements should also help on ARM targets - An

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

On 25/10/18 20:13, Florian Klämpfl wrote: Am 25.10.2018 um 18:59 schrieb Jonas Maebe: On 20/10/18 16:07, Simon Kissel wrote: - 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

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

Hi, On Thu, 25 Oct 2018, Florian Klaempfl wrote: > >> That is good news. The contours of a TODO list are becoming visible :) > >> > >> But we may need also need a solution for other platforms, which means the > >> current system should remain in place for those platforms where such a > >>

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

On 20/10/18 16:07, Simon Kissel wrote: - 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. The current state of the LLVM code generator is that

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

Am 25.10.2018 um 09:06 schrieb Sven Barth via fpc-devel: Simon Kissel > schrieb am Do., 25. Okt. 2018, 08:54: - Complete the LLVM branch of FPC. It looks like Jonas has stopped   working on it two years ago, which is a pity. I personally don't

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

Am 25.10.2018 um 11:18 schrieb Sven Barth via fpc-devel: Michael Van Canneyt > schrieb am Do., 25. Okt. 2018, 09:38: On Sat, 20 Oct 2018, Simon Kissel wrote: > - Make Exception handling, TLS etc use the infrastructure that >  libpthread is

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

Am 25.10.2018 um 17:38 schrieb Karoly Balogh (Charlie/SGR): Hi, On Thu, 25 Oct 2018, Michael Van Canneyt wrote: - Make Exception handling, TLS etc use the infrastructure that libpthread is providing TLS is handled already by libpthread. I doubt you will gain much there. GCC has

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

Hi, On Thu, 25 Oct 2018, Michael Van Canneyt wrote: > >>> - Make Exception handling, TLS etc use the infrastructure that > >>> libpthread is providing > >> > >> TLS is handled already by libpthread. I doubt you will gain much there. > >> > > > > GCC has (depending on the platform) a faster

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

On Thu, 25 Oct 2018, Sven Barth via fpc-devel wrote: Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 09:38: On Sat, 20 Oct 2018, Simon Kissel wrote: - Make Exception handling, TLS etc use the infrastructure that libpthread is providing TLS is handled already by libpthread. I

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

Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 09:38: > > > On Sat, 20 Oct 2018, Simon Kissel wrote: > > > - Make Exception handling, TLS etc use the infrastructure that > > libpthread is providing > > TLS is handled already by libpthread. I doubt you will gain much there. > GCC has

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

Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 14:55: > > > On Thu, 25 Oct 2018, Sven Barth via fpc-devel wrote: > > > > >> Personally I am also in favour of a more open technique instead of a > >> technique which is proprietary to a platform, and in this sense I > >> understand > >> and

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

On Thu, 25 Oct 2018, Sven Barth via fpc-devel wrote: Personally I am also in favour of a more open technique instead of a technique which is proprietary to a platform, and in this sense I understand and endorse your point of view, but beggars can't be choosers. There is no problem to have

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

Hello Simon - wondering if you have code examples that provoke problems you are experiencing? It will be easier to measure/test improvements with test cases. Solutions might not come from a single person/team and therefore not sure how to apply the bounty in the most effective/fair way.

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

Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 11:51: > > > On Thu, 25 Oct 2018, Sven Barth via fpc-devel wrote: > > > Michael Van Canneyt schrieb am Do., 25. Okt. > 2018, > > 09:38: > > > >> > >> > >> On Sat, 20 Oct 2018, Simon Kissel wrote: > >> > >>> - Make Exception handling, TLS etc

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

On Thu, 25 Oct 2018, Martin Schreiber wrote: On Thursday 25 October 2018 11:18:58 Sven Barth via fpc-devel wrote: I'm against emulating SEH. Better implement DWARF exceptions. The infrastructure that was created for SEH inside the compiler should help nevertheless. MSElang has some code

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

On Thu, 25 Oct 2018, Sven Barth via fpc-devel wrote: Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 09:38: On Sat, 20 Oct 2018, Simon Kissel wrote: - Make Exception handling, TLS etc use the infrastructure that libpthread is providing TLS is handled already by libpthread. I

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

On Thursday 25 October 2018 11:18:58 Sven Barth via fpc-devel wrote: > > I'm against emulating SEH. Better implement DWARF exceptions. The > infrastructure that was created for SEH inside the compiler should help > nevertheless. > MSElang has some code for "Itanium ABI Zero-cost Exception

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

Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 09:38: > > > On Sat, 20 Oct 2018, Simon Kissel wrote: > > > - Make Exception handling, TLS etc use the infrastructure that > > libpthread is providing > > TLS is handled already by libpthread. I doubt you will gain much there. > > However,

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

On Sat, 20 Oct 2018, Simon Kissel wrote: - Make Exception handling, TLS etc use the infrastructure that libpthread is providing TLS is handled already by libpthread. I doubt you will gain much there. However, Exception handling is a problem. There are 2 possible ways ahead: - DWARF

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

Simon Kissel schrieb am Do., 25. Okt. 2018, 08:54: > - Complete the LLVM branch of FPC. It looks like Jonas has stopped > working on it two years ago, which is a pity. > I personally don't think that LLVM is the way to go. It's essentially a moving target and adds an unnecessary dependency to