Re: [fpc-devel] The 15k bounty: Optimizing executable speed forLinux x86 / LLVM
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 simon.kis...@nerdherrschaft.com 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [3]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: -- [1] https://github.com/Soldat/PasZlib-SG [2] mailto:fpc-devel@lists.freepascal.org [3] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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: [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). Any clues? BR, Simon ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] New Debugging Aid
Hi everyone, I developed an aid to help me debug the peephole optimizer a while ago, and I would like to present it as a possible permanent fixture to the compiler if it is built with a particular define (DEBUG_ASMOUTPUT) - what it does... during each pass of the peephole optimizer under i386 or x86_64 (the only platforms that currently have implementations - other platforms won't do anything), the assembly of the current block is dumped to the console in a colour-coded fashion for ease of identification. It's not something you would normally build the compiler with, since the console dump significantly increases the compilation time of a project, but if you have the compiler open in a debugger, say, it allows you to see what the peephole optimizer is working on if you put a breakpoint at the beginning of the loop, say. That way, you can see how the peephole optimiser has modified the code and thus more easily identify bugs when refactoring routines or adding new features. I myself have been using it to help with debugging my optimizer overhaul project. Details can be found here: https://bugs.freepascal.org/view.php?id=34642 Gareth aka. Kit ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abstract generics
Am Mo., 3. Dez. 2018, 15:16 hat Simon Jackson geschrieben: > Further to the ranges in generics discussion... more on generics > I've already mentioned my reasons against that. So throwing around strange syntax extensions does not help. At all. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stringlist customsort
On 12/2/18 8:56 AM, Franz Müller wrote: @Tomas Hajny Ah - thank you. Very strange. I did not expect and did not notice that when I click on "reply to list", the reply uses another mail address than the one the mail was sent to. > Looks like an error of the thunderbird mailprogramm, are you using a combined mailbox for all accounts? i have multiple accounts here but they are each fully separated... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM code generator
On 03/12/2018 07:57, Ryan Joseph wrote: What does this mean for end users? Do we get better debugging support in LLDB? Sorry for getting slightly off topic (replies to lazarus list pleas / or fpc other). Lazarus 2.0 has an LLDB based debugger, that uses it's own code (fpdebug) for watches. For the OS all debugging goes via LLDB, but the IDE translates watches/locals (input expression and result) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM code generator
On 2018-12-03 07:57, Ryan Joseph wrote: On Dec 2, 2018, at 5:26 PM, Jonas Maebe wrote: The LLVM code generator is more or less ready, including Dwarf-EH-based exception handling support. It's currently only supported on Darwin/x86-64 and Linux/x86-64, but it can do a "make all" and the testsuite can be finished as well. There are still some extra failures that do not happen with the built-in code generator, but most tests work fine. What does this mean for end users? An option to exchange (a lot of) compilation speed for faster code. Do we get better debugging support in LLDB? Unlikely. That would at best be a trade-off (possibly better support as long as you consider the source as C++ instead of Pascal), and something for which you don't need an LLVM-based code generator. That mainly requires patches to LLDB to add support for Pascal-specific types and features. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM code generator
On 2018-12-02 17:25, Marģers . via fpc-devel wrote: >> ** Linux: you may also have to specify the library path to libgcc_s. >> E.g. on Ubuntu 16.04: >> make LOCALOPT="-dllvm -Fullvm -Fl/usr/lib/gcc/x86_64-linux-gnu/5" >> OPT="-Fullvm -Fl/usr/lib/gcc/x86_64-linux-gnu/5" all -j 4 FPMAKEOPT="-T >> 4" > > compilation does not work for me with those options. I keep getting following > error > > Fatal: Cannot open whole program optimization feedback file > "/home/blabla/src/llvm/compiler/pp1.wpo" > Fatal: Compilation aborted > Makefile:3912: recipe for target 'system.ppu' failed > > Problem is LOCALOPT. As soon it is as parameter for make, then wpo files are > not created. Strange. You can add NOWPOCYCLE=1 to disable the cycle with wpo. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Abstract generics
Further to the ranges in generics discussion... more on generics There is always a way to do that using an abstract class. The things of interest creating the idea are: 1. Imagine a short hand syntax for abstract classes: Generic classAbs = class(TObject) Class generic variable: TObject; End; abClass = specialize classAbs; // This allows a short hand, and 2. Some possible crazy inheritance: Generic classAbs = class(Q) Class generic variable: TObject; End; abClass = specialize classAbs; // which allows a form of polymorphic inheritance similar to interfaces, but short hand for interface variables. 3. Some code optimization for less cache thrashing Class generic procedure classAbs.doSomething(T); //generic procedure x.y(T); this also Begin // enforce no usage of field and methods on T, such as T.specificToClass() // allows same piece of code to be used for all types of same sizeof() // so less code to fill the L1 instruction cache, and the L2 cache is less burdened // of course this speed and code size optimization could be detected without this // but enforcing it could always be an option. End; 4. Compile time virtual kind of resolution // As an abstract class would have many virtual abstract methods there would be a pointer indirection from the VMT. // Any generic procedure or method could, if not virtual, be compiled in and so not need a virtual specifier. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] wrong step-over with fpc debug info / how to do objcopy on Mac, or strip .debug_frame
With reference to https://bugs.freepascal.org/view.php?id=34159
It *appears* that this issue also happens on Mac, using lldb (so both
lldb and gdb get step-over wrong, with debug info from fpc).
Posts by "bigDan":
http://forum.lazarus-ide.org/index.php/topic,42869.msg303599.html#msg303599
The log he provided shows that
- lldb got a "thread step-over"
- lldb believed to have stopped at the end of step-over (not any other
reason): "stop reason = step over"
- the active thread remained the same. So stepping was done in the
correct thread
- the called subroutine is located at a different address (not inlined)
pc before stepping (in calling code) 0x000100059d8e
pc after stepping (in subroutine) 0x0001002718e8
- the stackpointer was reduced by 8, and the stackframe register was NOT
yet modified.
So the stop was in the prologue ("begin" line of function)
On windows one way to solve the problem was to get rid of .debug_frame info.
It would be interesting to test if that happens on Mac too.
Does anyone know how to strip that info of the app bundle?
Rebuilding with a different version of Fpc or Lazarus may not be useful
for testing. Tiny changes anywhere in the codebase may require a
new/different test case.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] x86_64 Optimizer Overhaul
I run it no linux. Problem code part.
type PLongData = ^TLongData;
TLongData = array [0..100] of longint;
function binarySearchLong ( sortedArray:PLongData; nLen, toFind:longint):longint;
var low, high, mid, l, h, m : longint;
begin
{ Returns index of toFind in sortedArray, or -1 if not found}
low := 0;
high := nLen - 1;
l := sortedArray^[low];
h := sortedArray^[high];
while ((l <= toFind) and (h >= toFind)) do
begin
mid := (low + high) shr 1; { var "low" in register r8d }
m := sortedArray^[mid];
if (m < toFind) then
begin
low := mid + 1;
l := sortedArray^[low];
{ asm code generated
-- with trunk
lea r8d, [r11d+1H]
mov esi, r8d
--end trunk
-- with overhaul it never set r8d to new value, but should
lea esi, [r11d+1H]
-- end overhaul
mov r10d, dword [rdi+rsi*4]
jmp ?_00144
}
end else
if (m > toFind) then
begin
high := mid - 1;
h := sortedArray^[high];
end else
begin
binarySearchLong:=mid;
exit;
end;
end;
if (sortedArray^[low] = toFind) then
begin
binarySearchLong:=low;
end else
binarySearchLong := -1; { Not found}
end;
- Reply to message -
Subject: Re: [fpc-devel] x86_64 Optimizer Overhaul
Date: 2018. gada 2. decembris 23:32:36
From: J. Gareth Moreton
To: FPC developers' list
Thanks for the feedback. Do you have a reproducible case, and does it fail on Linux or Windows? I'll have a look for the infinite loops in the meantime.
Gareth aka. Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] x86_64 Optimizer Overhaul
> I've had problems testing it under Linux due to configuration difficulties, so if anyone is willing to try out "make all", I'll be most grateful. "make all" work well on linux. Compiler options -O3 and -O4 are broken. It was possible to compile my program, but program at some point went into never ending loop - cpu usage 100% and response zero. Compiling my speed test program using -O2, optimizations made by Overhaul, was speed lose by 2% comparing to current trunk. I guess, optimizations is good for compiler itself, but no so much for user programs. margers ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] LLVM code generator
> The support is currently only on the > https://svn.freepascal.org/FPC/svn/fpc/branches/debug_eh branch. I got sources from https://svn.freepascal.org/svn/fpc/branches/debug_eh > ** Linux: you may also have to specify the library path to libgcc_s. > E.g. on Ubuntu 16.04: > make LOCALOPT="-dllvm -Fullvm -Fl/usr/lib/gcc/x86_64-linux-gnu/5" > OPT="-Fullvm -Fl/usr/lib/gcc/x86_64-linux-gnu/5" all -j 4 FPMAKEOPT="-T > 4" compilation does not work for me with those options. I keep getting following error Fatal: Cannot open whole program optimization feedback file "/home/blabla/src/llvm/compiler/pp1.wpo" Fatal: Compilation aborted Makefile:3912: recipe for target 'system.ppu' failed Problem is LOCALOPT. As soon it is as parameter for make, then wpo files are not created. margers ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stringlist customsort
@Tomas Hajny Ah - thank you. Very strange. I did not expect and did not notice that when I click on "reply to list", the reply uses another mail address than the one the mail was sent to. Looks like an error of the thunderbird mailprogramm, I think replies should always use the same mail address that the incoming mail used. Anyway, I will try to take care that in the future I send my replies to the list from my registered address. Franz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
