A regression like this is quite serious.  I'd recommend opening a bug report with a reproducible case so we can investigate and hopefully fix it within the day.
At the moment I'm experimenting with increasing the speed of the optimizer for x86_64, and then porting to i386 when it's proven successful.  Having teething problems though!

Gareth

On Tue 04/12/18 01:16 , Simon Kissel sent:
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: [cmp imm32,imm8s] invalid combination of
opcode and operands
 SBMath.pas(1934,5) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands
 SBMath.pas(1939,9) Error: Asm: [cmp imm32,imm8s] invalid combination of
opcode and operands
 SBMath.pas(1941,5) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands
 SBMath.pas(1946,9) Error: Asm: [cmp imm32,imm8s] invalid combination of
opcode and operands
 SBMath.pas(1948,5) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands
 SBMath.pas(1953,3) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands
 SBMath.pas(1954,3) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands
 SBMath.pas(1955,3) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands
 SBMath.pas(1972,3) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands
 SBMath.pas(1976,5) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands
 SBMath.pas(1981,5) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands
 SBMath.pas(1982,5) Error: Asm: [lea reg32,imm32] invalid combination of
opcode and operands

(-Tlinux -XPi386-linux- -CpPENTIUMM -O2 -OoCSE -CfSSE2 -Ooorderfields)

2.)

On ARM, I get Internal error 200603253 at various places:

SBMath.pas(1989,1) Fatal: Internal error 200603253 (sadly the line numbers are complete off for unknown reasons, so I can not find the actual source line causing this)

But also happens at various other places. Most easy to reproduce by compiling PasZLib-SG (e.g. https://github.com/Soldat/PasZlib-SG [1]).

Any clues?

BR,

Simon

Hi Gareth,

A regression like this is quite serious. I'd recommend opening a bug report with a reproducible case so we can investigate and hopefully fix it within the day.

created a test project, and opened two tickets:

https://bugs.freepascal.org/view.php?id=34646
https://bugs.freepascal.org/view.php?id=34647

At the moment I'm experimenting with increasing the speed of the optimizer for x86_64, and then porting to i386 when it's proven successful. Having teething problems though!

Sounds great. I wish more of our products had 64bit CPUs...

What's the speed-up you are seeing on my test project so far?

Best regards,

Simon

The more you learn!  What is TLS, curiously? Given that I do a lot of my work at the assembler level, I figure this is something I should know!

Gareth

On Tue 04/12/18 22:48 , Simon Kissel sent:
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

Am Mi., 5. Dez. 2018, 00:06 hat J. Gareth Moreton
geschrieben:

The more you learn! What is TLS, curiously? Given that I do a lot of my work at the assembler level, I figure this is something I should know!

Thread Local Storage. For ELF they are pseudo instructions that the assembler needs to expand to the correct instructions for the target (and TLS model), which is why the internal assembler does not handle them yet.

Regards,
Sven

Hi & happy new year,

https://bugs.freepascal.org/view.php?id=34646 https://bugs.freepascal.org/view.php?id=34647

any chance that someone could have a look at those tickets? We are kinda blocked in advancing in the bounty if we can't use the improved compiler to benchmark our code...

Thank you!

Cheers,

Simon

Please disregard this. Problems were solved using the external assembler, so this isn't urgent (still would be nice if the internal assembler could be fixed).

BR,

Simon

Best regards,

Simon Kissel

The debug_eh branch contains now support for dwarf based exception handling for i386-linux.

Testing fpc/tests/bench/bansi1.pp gives with trunk

Test 1: 1000000 done in 0.367 sec
Test 2: 1000000 done in 0.414 sec
Test 3: 1000000 done in 0.359 sec

while with debug_eh it results in

Test 1: 1000000 done in 0.337 sec
Test 2: 1000000 done in 0.310 sec
Test 3: 1000000 done in 0.315 sec

The debug_eh branch can be build with e.g. from x86_64-linux

make all OS_TARGET=linux CPU_TARGET=i386 -j OPT="-XP -dpsabieh -Aas" CROSSOPT="-Fl/lib/i386-linux-gnu/ -Fl/usr/lib/gcc/i686-linux-gnu/8/"

or natively:

make all -j OPT="-dpsabieh -Aas" OPT="-Fl/lib/i386-linux-gnu/ -Fl/usr/lib/gcc/i686-linux-gnu/8/"

/usr/lib/gcc/i686-linux-gnu/8 needs to be adapted to the build system, libgcc_s must be found.

The library pathes need to be passed when compiling a program as well, also -Aas is needed.

The debug_eh branch contains also the tls threadvar support, so this can be enabled when building by -dtls_threadvars as well.

Oh, and Kylix:

This module must be distributed under the terms of the GNU General Public License (GPL), version 2. A copy of this license can be found at:http://www.borland.com/kylix/gpl.html.
Test 1: 1000000 done in 0.819 sec
Test 2: 1000000 done in 0.826 sec
Test 3: 1000000 done in 0.794 sec

For Simon's benchmark is does not help though as it is not using exception frames in the hot spots.