Re: [fpc-devel] LLVM code generator
> 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? Do we get better debugging support in LLDB? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Type range in generic
Am Mo., 3. Dez. 2018, 00:33 hat Simon Jackson geschrieben: > Just an idea. > > Class variables. If generics are used, then the same code can be used for > differing pointer types. (Classes) as long as a specifier on the "generic > class variable" and no generic specialize or <> is in the > > class generic x: TObject; > > Can it be shared across all generics of a kind? > > The code density in the cache would be good for all common generics. > I don't see a use for such a feature. What if one sets it as a descendant of one class, but another retrieves it as a descendent of a completely different class? You'd have to use separate storage locations then anyway and then you can simply use ordinary class variables. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Type range in generic
> On Dec 3, 2018, at 6:33 AM, Simon Jackson wrote: > > Just an idea. > > Class variables. If generics are used, then the same code can be used for > differing pointer types. (Classes) as long as a specifier on the "generic > class variable" and no generic specialize or <> is in the > > class generic x: TObject; > > Can it be shared across all generics of a kind? > > The code density in the cache would be good for all common generics. I don’t get what this is trying to accomplish or how it’s used. Example? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Type range in generic
Just an idea. Class variables. If generics are used, then the same code can be used for differing pointer types. (Classes) as long as a specifier on the "generic class variable" and no generic specialize or <> is in the class generic x: TObject; Can it be shared across all generics of a kind? The code density in the cache would be good for all common generics. https://kring.co.uk From: fpc-devel on behalf of Sven Barth via fpc-devel Sent: Sunday, December 2, 2018 4:01:44 PM To: FPC developers' list Cc: Sven Barth Subject: Re: [fpc-devel] Type range in generic Am So., 2. Dez. 2018, 10:50 hat Ryan Joseph mailto:r...@thealchemistguild.com>> geschrieben: > On Dec 2, 2018, at 4:00 PM, Sven Barth via fpc-devel > mailto:fpc-devel@lists.freepascal.org>> wrote: > > Please report as a bug. I don’t get a bug on this in the trunk version I’m using. Maybe it was fixed? Could be, I didn't test yet. But even then it can be resolved with "no change required". ;) (and be added as a test case) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] x86_64 Optimizer Overhaul
That's interesting. Thanks for that. Time to get fixing.
In the meantime I'm also fixing up the buggy optimisation that caused the
original crash on Linux... nothing against the contributor, but it looks
like some badly-copied code from the MovXX routine... it even still
mentions "movsx" in the comments!
Hopefully this effort on the overhaul won't all be for naught.
Gareth aka. Kit
On Sun 02/12/18 23:21 , "Marģers ." margers.ro...@inbox.lv sent:
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)) 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
Re: [fpc-devel] x86_64 Optimizer Overhaul
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 On Sun 02/12/18 20:54 , "Marģers ." margers.ro...@inbox.lv sent: > 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
Re: [fpc-devel] Type range in generic
Am So., 2. Dez. 2018, 10:50 hat Ryan Joseph geschrieben: > > > > On Dec 2, 2018, at 4:00 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Please report as a bug. > > I don’t get a bug on this in the trunk version I’m using. Maybe it was > fixed? > Could be, I didn't test yet. But even then it can be resolved with "no change required". ;) (and be added as a test case) Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] LLVM code generator
Hi, 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 still needs to be done: * investigate the RTE 217 when you compile a program with an error in it * add support for a volatile() built-in function similar to how we have unaligned(), to fix e.g. the endless loop in tests/test/tmt1 (or in general: global variables used for cross-thread synchronisation) * add support for specifying the target LLVM version. Currently it's hard-coded to LLVM 3.9, although it works all the way up to at least LLVM 7.0. Specifying the version number would mainly be necessary (for now) to target older LLVM versions * check some remaining test failures * add support for more platforms. Windows will be harder (and not something I plan on working any time soon), because I have not yet added support for generating LLVM-based exception handling code that is needed for SEH-based exception handling. Other 64 bit platforms should be "reasonably" easy (the parameter handling needs to be generalised more though). 32 bit platforms will probably require either some compiler re-engineering, hacking, or a translation of the tcg64 code generator to some kind of high-level code generator as well. * add support for generating debug info * add support for generating more meta-information for optimizations (e.g. range information about subrange types and enums) * add support for saving the bitcode in addition to the native object files, and subsequently using link-time optimisation * add support for some custom calling conventions * pass on more FPC-related code generation options to LLVM (currently, mainly -CfXXX and -Ox get passed on) * add support for TLS-based threadvars Known limitations: * hardware exceptions are unsupported. They will be caught, but unwinding is hit-and-miss because the state of the registers may be completely different than what LLVM expects (higher optimisation levels = more chance it will fail). This is an LLVM limitation and not something that can be fixed in FPC. It's also a major source of extra tests failures. The support is currently only on the https://svn.freepascal.org/FPC/svn/fpc/branches/debug_eh branch. To test: * make sure you have clang on your system (the ones from Xcode work fine too) and that it's in your path. If not, you can download one from http://releases.llvm.org/download.html#7.0.0 * build FPC as follows ** Darwin (can also use a higher version than 10.6, but the built-in default --10.5--- won't work): make LOCALOPT="-dllvm -Fullvm" OPT="-WM10.6" all ** 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" The LOCALOPT flags are only used while building the compiler. They're separate here because otherwise you get errors while building the IDE (the -Fullvm doesn't work there while -dllvm would still make it use llvm units). This does mean that IDE will be built without the LLVM code generator, and hence its built-in compiler won't generate working code because it won't use Dwarf-EH-based exception handling, while the RTL will only contain support for that kind of exception handling. Note that on Linux, all generated binaries will be dynamically linked and depend on libc (and libgcc_s), unlike with the regular code generator. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stringlist customsort
On Sat, December 1, 2018 22:24, Franz Müller wrote: . . > BTW.: @ Tomas Hyjny: What made you think that I am not subscribed to the > mailing list? The fact that all your posts sent from the e-mail address used for sending them (@focusdata.at) are held in the moderation queue waiting for approval and marked as sent from an address not subscribed to the list in the list moderation interface. ;-) Checking the list of members manually gives the same result. Obviously, you may be subscribed using a different address, there's no way for finding out that some other address among the many subscribed ones belongs to you as well. Anyway, if this is the case, but you prefer being able to send messages to the list using both addresses, it's the best to subscribe both, but set one of them (whichever you like) to non-delivery mode. Then your posts will be recognized as coming from one of the list members and delivered without delays and you'll keep receiving the messages only once and just to the address you choose. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Type range in generic
> On Dec 2, 2018, at 4:00 PM, Sven Barth via fpc-devel > wrote: > > Please report as a bug. I don’t get a bug on this in the trunk version I’m using. Maybe it was fixed? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stringlist customsort
Am 01.12.2018 um 09:09 schrieb fpc-devel-requ...@lists.freepascal.org: That sounds as if you have an implementation ready ? If so, please submit a patch to the bugtracker. I'll evaluate it and if it is indeed simple, as you claim, I will apply the patch. Michael. Havent programmed it yet, but I am going to do now. This is my first contribution to the project, so most work for me will be to download trunc, learn how create a patch etc. The implemetation of the new feature should be rather simple. I will do that and submit the patch to the bugtracker. BTW.: @ Tomas Hyjny: What made you think that I am not subscribed to the mailing list? Franz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Type range in generic
Am Sa., 1. Dez. 2018, 08:44 hat Simon Jackson geschrieben: > GENERIC GHandle = CLASS > PROTECTED > it: Array [R] of T; > FUNCTION readIt(p: R): T; VIRTUAL; > PROCEDURE WriteIt(p: R; what: T); VIRTUAL; > PUBLIC > PROPERTY gimmeIt[p: R] READ ReadIt WRITE Writeit; DEFAULT; (* does this > work? x.y -> x.it.y *) > END; > > Error: Error in type definition just after R on line 3. > Please report as a bug. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
