On 05 Apr 2009, at 13:28, JoshyFun wrote:
JM> If you use FPC 2.3.1 with whole-program optimization and the
compiler
JM> can prove that it is never callable: yes. See
JM> http://wiki.freepascal.org/Whole_Program_Optimization
JM> for more information. In case this is in relation to the
thread on
JM> the Lazarus list about the big executables: note that it has
only a
Yes and no :) The thread raises the question in my brain :) but not to
reduce the LCL final size, it was only a conceptual question, how can
the compiler determine that a virtual method is unused at all,
If you have a class hierarchy tbase->tderived1->tderived2 with a
virtual method called "vmethod", and nowhere in the program there is a
call to vmethod, then it is unused. Or if it is only called using
tderived2 instances, then if the linker does not find any direct
references to tderived1.vmethod or tbase.vmethod (e.g., via
"inherited" calls from tderived2 methods), it knows that the VMT
entries for vmethod in tderived1 and tbase can be set to nil.
and
even if it is removed the VMT entry should be present do not ?
The easiest is to keep it, but simply set it to nil or to
FPC_ABSTRACTERROR. Then you don't have to start juggling with changing
offsets everywhere.
JM> The internal linker can also do it (only throwing away virtual
method
[...]
JM> that produces an error if you try to link a unit compiled with the
JM> option using the external linker), but that hasn't been done yet.
Just for curiosity which is the parameter set ?
Compile the compiler with -dvtentry. It's not been tested for a while
though, as far as I know.
I also made a mistake in my previous explanation: currently, the WPO
does not yet perform the optimization the -dvtentry does. -dvtentry
looks at which VMT entries of a class hierarchy are never accessed,
and replaces those by nil. As a result, if those methods are not
referred directly, then they can be removed by the linker.
The WPO looks at which class types can be instantiated in the program
and at the inheritance tree, and based on this determines which
virtual method calls can be replaced by non-virtual method calls (and
for those methods, it replaces the VMT entry with FPC_ABSTRACTERROR).
It also replaces the VMT entries for (non-class) virtual methods in
all classes that cannot be instantiated in the program with
FPC_ABSTRACTERROR. As a result, again if such methods are not
referenced directly, then they can be removed by the linker (and the
ones that are referenced can be turned into normal function calls).
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
