Excellent work Florian! Makes me want to work on those parts of the
compiler.. Though my current interests are in other parts of it.
But very nice. :)
On 14-01-25 04:55 PM, Florian Klämpfl wrote:
Am 25.01.2014 23:00, schrieb Sven Barth:
On 25.01.2014 17:09, Florian Klaempfl wrote:
Am 24.01.20
Am 25.01.2014 23:33, schrieb Nico Erfurth:
> On 25.01.14 17:09, Florian Klaempfl wrote:
>
>> Still WIP :) But a lot of my commits from the last weeks are spin-offs
>> of the SSA work.
>>
>> Together with all other improvements this results in significant better
>> code:
>>
>> fpc -l -O3 sha256.pp
On 25.01.14 17:09, Florian Klaempfl wrote:
> Still WIP :) But a lot of my commits from the last weeks are spin-offs
> of the SSA work.
>
> Together with all other improvements this results in significant better
> code:
>
> fpc -l -O3 sha256.pp -S2
> Free Pascal Compiler version 2.6.2 [2013/02/12
Am 25.01.2014 23:00, schrieb Sven Barth:
> On 25.01.2014 17:09, Florian Klaempfl wrote:
>> Am 24.01.2014 09:32, schrieb Sven Barth:
>>> Am 24.01.2014 02:03, schrieb Martin Frb:
There is a bigger example, where exactly that was done, because FPCs
optimization was not sufficient enough for
On 25.01.2014 17:09, Florian Klaempfl wrote:
Am 24.01.2014 09:32, schrieb Sven Barth:
Am 24.01.2014 02:03, schrieb Martin Frb:
There is a bigger example, where exactly that was done, because FPCs
optimization was not sufficient enough for what the author wanted.
http://bugs.freepascal.org/view.
Am 24.01.2014 09:32, schrieb Sven Barth:
Am 24.01.2014 02:03, schrieb Martin Frb:
There is a bigger example, where exactly that was done, because FPCs
optimization was not sufficient enough for what the author wanted.
http://bugs.freepascal.org/view.php?id=10275
In that context... @Florian: how
Am 24.01.2014 02:03, schrieb Martin Frb:
There is a bigger example, where exactly that was done, because FPCs
optimization was not sufficient enough for what the author wanted.
http://bugs.freepascal.org/view.php?id=10275
In that context... @Florian: how is your SSA support coming along? :)
Re
On 24/01/2014 01:03, Martin Frb wrote:
Until that is done, your best choice, if you need the speed is to do
this by hand:
or better
if cnt = 0 then exit;
tmpptrA := @a[0];
tmpptrB := @b[0];
for i := 0 to cnt - 1 do
begin
tmpVAlue := tmpptrA^ + tmpptrB^;
tmpptrA^ := tmpVAlue;
On 24/01/2014 00:17, August Oktobar wrote:
"2) Reporter's assumption about fstp is wrong: the first fstp
instruction removes value from fpu stack, so it cannot be used for the
second time without first reloading value onto stack."
Compiler should reuse loaded value (a[i]) and store to a[i] usi
"2) Reporter's assumption about fstp is wrong: the first fstp instruction
removes value from fpu stack, so it cannot be used for the second time
without first reloading value onto stack."
Compiler should reuse loaded value (a[i]) and store to a[i] using fstl,
then fstpl to a[i+1]
On Fri, Jan 24,
24.01.2014 3:04, Martin Frb пишет:
On 23/01/2014 22:26, August Oktobar wrote:
Hello, I have seen your mails about peephole optimization, so I wonder if you
could look at this
reports
http://bugs.freepascal.org/view.php?id=23595
or perhaps optimize slow array access using operator [] (it is fas
On 23/01/2014 22:26, August Oktobar wrote:
Hello, I have seen your mails about peephole optimization, so I wonder
if you could look at this reports
http://bugs.freepascal.org/view.php?id=23595
or perhaps optimize slow array access using operator [] (it is faster
to use pointer arithmetics)
t
12 matches
Mail list logo