[fpc-devel] Const optimization is a serious bug

[Sven Barth]

Am 08.07.2011 12:05, schrieb Jonas Maebe:
>> However, looking at the generated assembly, I can't believe there
>> isn't a more efficient way to handle the implicit try-finally. It
>> feels to me like that is where the problem is. There is a lot of code
>> and several function calls that go into implementing that implicit
>> 'finally' block. There's got to be some way to decrement the refcount
>> even when there are exceptions but without so much overhead. It would
>> require changes to the exception handling mechanism though. Here my
>> knowledge runs out.
>
> The main problem here is that FPC's exception handling is based on
> setjump/longjump. This technique has a relatively high overhead for
> "try", but low overhead when an exception actually occurs (of course,
> since exceptions are supposed to happen only exceptionally, that's not a
> really good selling point). The main reason we use it is because it's
> easy to implement.
>
> A better approach would be to use SEH-based exception handling (which
> has no overhead at all for "try", and a high overhead in case an
> exception occurs), but that woud require
> a) support for generating EH frames for all platforms (it's currently
> only supported for a number of i386 and x86-64 platforms)
> b) support for parsing EH frames on all platforms and performing
> exception handling based on that
>
> This is definitely something we want, but nobody has found the time yet
> to implement it.

Around a year ago I've experimented with using SEH on Windows (I have 
not reached a working state back then). It's on my list to revive this 
again, but before that I want to have Delphi compatible generics and 
extended RTTI with attributes working :D

Regards,
Sven