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: 100 done in 0.367 sec
Test 2: 100 done in 0.414 sec
Test 3: 100 done in 0.359 sec
while with debug_eh it results in
Test 1:
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
Sunday, January 6, 2019, 10:17:36 PM, you wrote:
> Hi & happy new year,
>> https://bugs.freepascal.org/view.php?id=34646
>>
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
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
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 simon.kis...@nerdherrschaft.com sent:
Hi Florian,
> Do you compile with -Aas? The internal assemblers
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
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
At the moment, I'm experimenting with overhauling the x86_64 optimizer to
see if I can reduce the number of passes through a block of code - my hope
is to greatly increase the speed of the compiler without sacrificing the
optimisations performed under -O1 and -O2. At present, I've attempted to
On Sun, Oct 28, 2018 at 12:40 AM J. Gareth Moreton <
gar...@moreton-family.com> wrote:
> Part of my incentive is that I like to design games and am also an amateur
> mathematician, both fields that can benefit from speed gains, so if I can
> make Free Pascal into something that is suitable for
Hi Gareth,
> And unfortunately not many of us have
> access to Kylix.
I can have a look if a can package something that works
based on the old Open Edition of Kylix for those who
don't have an Kylix ISO floating around.
Simon
___
fpc-devel maillist
Hi Michael,
> I think that specific improvements should be specified, and a bounty for
> each of these improvements should be specified, instead of an overall
> bounty.
I agree. Let's agree on a list of improvements, and spread
to bounty accordingly.
Simon
To add my two pence to this:
Low-level optimisation is my personal speciality. Currently a lot of
what I do is on small savings within the peephole optimizer on x86
systems. Generally the result is that the compiler runs slightly more
slowly, but the final binary runs a bit more efficiently -
On Thu, 25 Oct 2018, J. Gareth Moreton wrote:
I would argue how such a bounty would be
rewarded here because overall performance
gains have been done by multiple
submitters. For example, I've submitted a
number of improvements to the optimiser to
produce both smaller and faster machine
I would argue how such a bounty would be
rewarded here because overall performance
gains have been done by multiple
submitters. For example, I've submitted a
number of improvements to the optimiser to
produce both smaller and faster machine
code.
And unfortunately not many of us have
14 matches
Mail list logo
