Jonas Maebe schrieb:
On 11 okt 2006, at 18:40, Florian Klaempfl wrote:
Since I found no test regression nor a problems with make all I
enabled the optimization for x86-64, i386, sparc and arm. I leave
powerpc(64) to Jonas, he might do so or not ;)
Yesterday I checked and could not find a si
On a side note, fixing branch priority (order? I like compiler
programming but I'm not very into it :-( ) takes the run time down by
about 20% on a Duron system...
Do you plan to add some related tricks to FPC? (I'm not talking about
the advanced "lively analysis" that is in the to-do, but rathe
On 11 okt 2006, at 18:40, Florian Klaempfl wrote:
Since I found no test regression nor a problems with make all I
enabled the optimization for x86-64, i386, sparc and arm. I leave
powerpc(64) to Jonas, he might do so or not ;)
Yesterday I checked and could not find a single difference in
Since I found no test regression nor a problems with make all I enabled
the optimization for x86-64, i386, sparc and arm. I leave powerpc(64) to
Jonas, he might do so or not ;)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.free
Florian Klaempfl schreef:
Vincent Snijders wrote:
I tried this with the recursive benchmark:
http://svn.freepascal.org/svn/fpc/trunk/tests/bench/shootout/src/recursive.pp
How much does leaving fwait away help?
There is a small, but measurable difference:
fpc 2.0.4: 9.04
fpc 2.0.4 without fwa
Vincent Snijders wrote:
> I tried this with the recursive benchmark:
> http://svn.freepascal.org/svn/fpc/trunk/tests/bench/shootout/src/recursive.pp
How much does leaving fwait away help?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://l
Florian Klaempfl schreef:
Daniël Mantione wrote:
Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
Yesterday, I've implemented tail recursion optimization
(http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas resulting in
http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11 i
Jonas Maebe wrote:
[...]
Well, basically I agree with all your points ;) That's why I said the
optimization is almost useless for real world programs. Nevertheless it helps
for the benchmarks and gcc does it to. I'll try to find out the influence on the
compiler/rtl, there are some examples where
On 10 okt 2006, at 13:46, Florian Klaempfl wrote:
Practical argument:
the assembler code _is_ better for the code I tested and up to as
twice as fast
as the original one.
That's indeed true for an extremely small function with so few local
variables/parameters that even on an i386 it doe
Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
> > There's a FlagsUsed field in the ttaiprop record which is set to true if
> > the flags result of that instruction is used.
>
> I guess it could be used to change to code above to
> leal 1(%esi),%eax
> ?
>
> Or is this slower on some CPUs?
In
Jonas Maebe wrote:
>> The recursive call is usually inside an if anyways so the ssa
>> optimizer is lost
>> anyways, no?
>
> For the part inside the if: yes. But not for the part coming before it.
> What's more important however is that goto/label not only removes the
> usage of SSA, it also means
On 10 okt 2006, at 11:09, Florian Klaempfl wrote:
Also, do you actually insert goto/label nodes? That would
degrade the performance of the register variable assignment
because of
the current limitations concerning flow analysis (i.e., for
sufficiently
complex routines, the tail recursion op
Jonas Maebe wrote:
>
> On 10 okt 2006, at 10:34, Florian Klaempfl wrote:
>
>> Not really. I didn't try it yet but it shouldn't mess up much. The
>> optimziation
>> is done completely on the node level, the pascal code would look like
>> http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=156
Op Tue, 10 Oct 2006, schreef Vinzent Hoefler:
> On Tuesday 10 October 2006 08:29, Florian Klaempfl wrote:
> > Daniël Mantione wrote:
> > > Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
> > >> Yesterday, I've implemented tail recursion optimization
> > >> (http://svn.freepascal.org/svn/fpc/trunk
Op Tue, 10 Oct 2006, schreef Micha Nelissen:
> Florian Klaempfl wrote:
> > Yesterday, I've implemented tail recursion optimization
> > (http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas resulting
> > in
> > http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11 is the
> > n
On 10 okt 2006, at 10:34, Florian Klaempfl wrote:
Not really. I didn't try it yet but it shouldn't mess up much. The
optimziation
is done completely on the node level, the pascal code would look like
http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=156 except
that there
are temps in
Florian Klaempfl wrote:
-OoTAILREC? -O3? Something different?
It doesn't always improve performance ? It takes much more code ?
?
I thought the difference between -O2 and -O3 is that -O3 is not actually
guaranteed to improve "global" performance, for example due to the code
expanding a lot
Vinzent Hoefler wrote:
> On Tuesday 10 October 2006 08:29, Florian Klaempfl wrote:
>> Daniël Mantione wrote:
>>> Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
Yesterday, I've implemented tail recursion optimization
(http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas
result
Micha Nelissen wrote:
> Florian Klaempfl wrote:
>> Yesterday, I've implemented tail recursion optimization
>> (http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas
>> resulting in
>> http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11 is
>> the new
>> compiler, fpc11 the old,
On Tuesday 10 October 2006 08:29, Florian Klaempfl wrote:
> Daniël Mantione wrote:
> > Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
> >> Yesterday, I've implemented tail recursion optimization
> >> (http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas
> >> resulting in
> >> http://www.hu.
Jonas Maebe wrote:
>
> On 10 okt 2006, at 10:05, Daniël Mantione wrote:
>
>> If the optimization needs significant processing power, -O3. If it
>> doesn't
>> but is debug safe, -O1, if it is not debug safe, -O2.
>
> It's definitely not debug safe, since it messes up stack information.
Not reall
Daniël Mantione wrote:
>
> Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
>
>> Yesterday, I've implemented tail recursion optimization
>> (http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas resulting in
>> http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11 is the new
>> c
Florian Klaempfl wrote:
Yesterday, I've implemented tail recursion optimization
(http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas resulting in
http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11 is the new
compiler, fpc11 the old, both are 2.1.1). It isn't enabled yet be
On 10 okt 2006, at 10:05, Daniël Mantione wrote:
If the optimization needs significant processing power, -O3. If it
doesn't
but is debug safe, -O1, if it is not debug safe, -O2.
It's definitely not debug safe, since it messes up stack information.
A separate option -OoTAILREC is IMHO not
Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
> Yesterday, I've implemented tail recursion optimization
> (http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas resulting in
> http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11 is the new
> compiler, fpc11 the old, both are
Yesterday, I've implemented tail recursion optimization
(http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas resulting in
http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11 is the new
compiler, fpc11 the old, both are 2.1.1). It isn't enabled yet because it still
needs some
26 matches
Mail list logo
