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

[Sven Barth]

Michael Van Canneyt <michael at freepascal.org> schrieb am Do., 25. Okt. 2018,
11:51:

>
>
> On Thu, 25 Oct 2018, Sven Barth via fpc-devel wrote:
>
> > Michael Van Canneyt <michael at freepascal.org> 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, Exception handling is a problem. There are 2 possible ways
> ahead:
> >> - DWARF exception handling as mentioned by Sven.
> >> - Port SEH to be cross platform, this is the approach as taken by Kylix.
> >> Kilyx has a small rtlunwind  library that mimics the needed run-time
> >> functionality
> >> offered by Windows.
> >>
> >> Conceivably, it can be duplicated. wine probably has such a library
> which
> >> can be used as an inspiration.
> >>
> >> The needed compiler infrastructure for SEH  already exists, so this is
> >> most likely
> >> the fastest way to proceed.
> >>
> >
> > I'm against emulating SEH. Better implement DWARF exceptions. The
> > infrastructure that was created for SEH inside the compiler should help
> > nevertheless.
>
> You can be against, and  you don't need to work on it,
> but if someone supplies a patch, I don't think we should refuse it.
>

I don't agree here.


> 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 both techniques available. As I wrote, the SEH
> is the fastest path.
>

I have my doubts especially as the rtlunwind stuff of Kylix only works on
i386. The SEH mechanism between i386 and all other Windows platforms
differs significantly and I doubt that Simon only wants i386 to benefit.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20181025/65c70f87/attachment.html>