Re: [fpc-devel] x86_64 Optimizer Overhaul

Sorry for hijacking the thread. Your mail client issue makes the conversation really hard to follow, so I have literally no idea what the current subtopic of a reply chain is, and there's little point in properly detaching a thread. Am 15.12.2018 um 18:13 schrieb J. Gareth Moreton: > I dare ask,

Re: [fpc-devel] x86_64 Optimizer Overhaul

On Sat, Dec 15, 2018 at 2:37 PM Martok wrote: > In any case, FPC's cmem on Win32 calls into mscvrt, and that is so slow > that I > killed the test code after a couple of minutes, where even FPC-builtin was > done > after 10 seconds. > Interesting. On Win64 I've found it to be consistently

Re: [fpc-devel] x86_64 Optimizer Overhaul

Apologies for my webmail client problems.  There's little I can do about that. This was the object pooling that I did - https://bugs.freepascal.org/view.php?id=34679 - though there's some cycle counting involved (e.g. in OptPass1MOV, only the integer registers are updated instead of all 8

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

Am Sa., 15. Dez. 2018, 23:55 hat Nikolai Zhubr geschrieben: > Hi, > > Is there any easy way to see how exactly ppcrossarm.exe invokes > assembler (command-line arguments passed) during a cross-compiler build > and also to inspect intermediate .s files? > You can try -sh which should generate a

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

On 12/15/18 11:57 AM, Nikolai Zhubr wrote: 15.12.2018 19:09, wkitt...@windstream.net: On 12/15/18 10:36 AM, Nikolai Zhubr wrote: So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ? is this a typo? should it be -CfVPF4_S16 with F and V swapped? No. From ppcrossarm.exe -i:

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

Hi, 16.12.2018 2:13, I wrote: Is there any easy way to see how exactly ppcrossarm.exe invokes assembler (command-line arguments passed) during a cross-compiler build and also to inspect intermediate .s files? Got it, somewhat: -mfpu=softvfp is passed to arm-linux-as while compiling

Re: [fpc-devel] Case block optimisation

I'll see what I can do! The one thing about my case optimisations here is that they're done at the node level.  Some parts are platform-independent, but unfortunately, things like jump table generation have to be implemented for each platform. The aint shuffling is a little difficult to test

Re: [fpc-devel] x86_64 Optimizer Overhaul

On 15/12/18 19:37, Ben Grasset wrote: Should this really be surprising at all though? To me it seems obvious why that would be the case. Delphi the compiler (not the IDE) is not written in Pascal. It's written in a combination of C and C++. Thus, I would imagine that Delphi's *default*

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

Hi again, 15.12.2018 19:52, Nikolai Zhubr: 15.12.2018 18:24, Florian Klämpfl: Now, I'm targeting an A20-olinuxino-micro board, which is afaik armv7a with VPFv4. The board is running either openwrt or opensuse. (And actually, the binaries produced by the pre-built native compiler have been

Re: [fpc-devel] x86_64 Optimizer Overhaul

On 15/12/18 21:04, Ben Grasset wrote: On Sat, Dec 15, 2018 at 2:43 PM Jonas Maebe > wrote: That is incorrect. I didn't mean that it doesn't *care* about being fast, but more that it will not necessarily use more memory in all cases that it might result in a

Re: [fpc-devel] x86_64 Optimizer Overhaul

Well, Florian did say he was concerned about the increased maintenance costs, given how complex the compiler is already.  Granted, it's one of the few surefire ways that I've sped up the compiler quite significantly.  Other speed-ups like other case block algorithms may also help. Though the

Re: [fpc-devel] Case block optimisation

Am 15.12.2018 um 18:08 schrieb J. Gareth Moreton: > So here's something else I've been playing with in the interim... I've been > working on improving the algorithms used when compiling case blocks.  It was > driven partly by my binary search idea for certain kinds of case block, which > I >

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

Hi, Is there any easy way to see how exactly ppcrossarm.exe invokes assembler (command-line arguments passed) during a cross-compiler build and also to inspect intermediate .s files? Thing is, object files compiled from pascal (like system.o) still get this suspicious VFP flag even after I

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

Hi all, Ok, apparently the binutils-2.15.94-win32-arm-linux.zip (provided on the fpc website) is somewhat outdated to be really usable for arm target. Retrying with (self-built) binutils-2.28 apparently solves the previous problem but now I have another: ld yells something about VFP

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

On 15/12/18 15:29, Nikolai Zhubr wrote: 15.12.2018 16:58, I wrote: C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP instructions, whereas .\pp does not C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

On 12/15/18 9:29 AM, Nikolai Zhubr wrote: I suspect this is an inintended flag set by my arm-linux-as.exe for some reason... Probably have to get rid of it somehow... so the real questions are: 1. is this flag being set erroneously? 2. are the .o files being built properly? 3. should

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

15.12.2018 16:58, I wrote: C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP instructions, whereas .\pp does not C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target specific data of file Hm, indeed, objdump

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

Am 15.12.2018 um 16:36 schrieb Nikolai Zhubr: >> There is no single ARM/Linux platform, but many different incompatible >> ones (which is one of the reasons there are no provided FPC >> cross-compilers for this "platform". > > Right, this is what I overlooked indeed (Well, because a pre-built

Re: [fpc-devel] x86_64 Optimizer Overhaul

Am 12.12.2018 um 13:49 schrieb Ryan Joseph: > > >> On Dec 12, 2018, at 7:20 PM, Martok wrote: >> >> Checking out the memory manager(s) could be useful as well - there are a lot >> of >> small allocations, that generally tends to put much stress on it. >> And any improvement there would also

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

15.12.2018 18:24, Florian Klämpfl: Now, I'm targeting an A20-olinuxino-micro board, which is afaik armv7a with VPFv4. The board is running either openwrt or opensuse. (And actually, the binaries produced by the pre-built native compiler have been tested in both environments already) So I

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

15.12.2018 19:09, wkitt...@windstream.net: On 12/15/18 10:36 AM, Nikolai Zhubr wrote: So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ? is this a typo? should it be -CfVPF4_S16 with F and V swapped? No. From ppcrossarm.exe -i: Supported FPU instruction sets:

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

15.12.2018 17:38, Jonas Maebe: T:\...3.0.4\fpcsrc\rtl\units\arm-linux>arm-linux-objdump.exe -p system.o system.o: file format elf32-littlearm private flags = 600: [APCS-32] [VFP float format] [software FP] I suspect this is an inintended flag set by my arm-linux-as.exe for some reason...

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

On 12/15/18 10:36 AM, Nikolai Zhubr wrote: So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ? is this a typo? should it be -CfVPF4_S16 with F and V swapped? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list

Re: [fpc-devel] x86_64 Optimizer Overhaul

Ah right, so things like "TmpUsedRegs" (an array of TUsedRegs) constantly being created and destroyed in the peephole optimizer is actually not that much of a penalty hit, and creating a pooled object for continuous use doesn't give that much of a performance gain? Gareth On Sat 15/12/18

Re: [fpc-devel] x86_64 Optimizer Overhaul

Am 15.12.2018 um 17:12 schrieb Florian Klämpfl: > The memory manager itself pools already, so no need for the compiler. If > somebody wants to improve the heap manager: > implement OS supported re-allocations (OS can move memory by just shuffling > pages). Very much agree, it's not a user

[fpc-devel] Case block optimisation

Hi everyone, So here's something else I've been playing with in the interim... I've been working on improving the algorithms used when compiling case blocks.  It was driven partly by my binary search idea for certain kinds of case block, which I wrote up over here:

Re: [fpc-devel] x86_64 Optimizer Overhaul

I dare ask, does that mean we should avoid workarounds in the compiler (and our own programs) that aim to avoid constant construction and destruction of objects, and instead try to improve the memory manager? So many discoveries! Gareth aka. Kit P.S. This thread is supposed to be for the

Re: [fpc-devel] x86_64 Optimizer Overhaul

On Sat, Dec 15, 2018 at 1:01 PM Martok wrote: > I just tested something, and I'm a surprised by how big the difference is. > Should this really be surprising at all though? To me it seems obvious why that would be the case. Delphi the compiler (not the IDE) is not written in Pascal. It's

Re: [fpc-devel] x86_64 Optimizer Overhaul

On Sat, Dec 15, 2018 at 1:14 PM J. Gareth Moreton wrote: > P.S. This thread is supposed to be for the x86_64 optimizer overhaul that > I presented! > Despite the other reply I just sent about the memory management stuff I also agree here! Your changes look very beneficial and it would be nice