On Tue, Nov 01, 2005 at 05:32:29PM +0100, Florian Weimer wrote:
> * Simon Marlow:
>
> > gcc started generating this rubbish around version 3.4, if I recall
> > correctly. I've tried disabling various optimisations, but can't seem
> > to convince gcc not to generate the extra jump. You don't get
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(
>
* > 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 nativ
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
* Simon Marlow:
> gcc started generating this rubbish around version 3.4, if I recall
> correctly. I've tried disabling various optimisations, but can't seem
> to convince gcc not to generate the extra jump. You don't get this from
> the native code generator, BTW.
But the comparison is present
* 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 for
