On Wed, 2 Nov 2005, skaller wrote:
On Tue, 2005-11-01 at 19:03 +0100, Florian Weimer wrote:
BTW, you shouldn't generate identifiers with leading underscores
because they are reserved for the implementation.
I AM the implementation :)
You are not the C implementation.
Generated
On Wed, 2005-11-02 at 19:47 +0100, Florian Weimer wrote:
It seems that the goto-based version leads to different static branch
prediction results, which happen to be favorable.
It has nothing to do with branch prediction. I know
it is determined ENTIRELY by stack use.
In both cases,
* John Meacham:
loop:
if () goto loop;
is not equivalent to a do-while loop, loop invarients cannot be hoisted out of
the above for instance (except in some cases... it is all quite tricky and we
want gcc to have as much freedom as possible).
do-while loops are converted to this form by
On Tue, 2005-11-01 at 17:30 +0100, Florian Weimer wrote:
use C control constructs rather than gotos.
With GCC version 4, this will have no effect because the gimplifier
converts everything to goto-style anyway.
Felix generates C with gotos. The result is FASTER
than native C using gcc 4.0
* On Tue, 2005-11-01 at 17:30 +0100, Florian Weimer wrote:
use C control constructs rather than gotos.
With GCC version 4, this will have no effect because the gimplifier
converts everything to goto-style anyway.
Felix generates C with gotos. The result is FASTER
than native C using gcc
On Tue, 2005-11-01 at 19:03 +0100, Florian Weimer wrote:
Felix generates C with gotos. The result is FASTER
than native C using gcc 4.0 on x86_64.
Coincidence. 8-)
Possibly :)
Felix generated C(++) code -- compiled with same options:
int FLX_REGPARM _i1860_f1301_ack(
int
(I apologize in advance if this message seems self congradulatory, but
after a long time of being disheartened by jhc only having marginal
gains over ghc, I am finally seeing some substantial benefits, many of
which are the result of optimizations that can actually be ported back
to ghc)
So,
Nice analysis. I indeed found with phc that shadow stack references
absolutely killed performance, and I aggressively cached stack
locations in locals, spilling to stack only when GC information
needed to be accurate. [There was a giant infrastructure to save
only live data to stack, but
On Wed, Oct 26, 2005 at 12:24:14PM -0400, Jan-Willem Maessen wrote:
Nice analysis. I indeed found with phc that shadow stack references
absolutely killed performance, and I aggressively cached stack
locations in locals, spilling to stack only when GC information
needed to be accurate.
