Re: [fpc-devel] Does FPC optimize unused parameters ?
Martin wrote on Wed, 08 Aug 2012:
On 08/08/2012 15:55, Jonas Maebe wrote:
{$macro on}
{$ifdef debugmsg}
{$define CallSendDebug:=SendDebug}
{$else}
{$define CallSendDebug:=//}
{$endif}
CallSendDebug('|');
Yes I have seen that, and even the macro for continues lines (if params wrap)
But it needs to be declared in each unit (or in an include).
The alternative has to be declared on each debug line...
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does FPC optimize unused parameters ?
On 08/08/2012 15:55, Jonas Maebe wrote:
It's possible to do that in a more compact way with a macro (the
following is used in a couple of places in the RTL):
{$macro on}
{$ifdef debugmsg}
{$define CallSendDebug:=SendDebug}
{$else}
{$define CallSendDebug:=//}
{$endif}
CallSendDebug('|');
Yes I have seen that, and even the macro for continues lines (if params
wrap)
But it needs to be declared in each unit (or in an include).
It doesn't simple come via using a unit.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does FPC optimize unused parameters ?
On 08/08/2012 15:47, michael.vancann...@wisa.be wrote:
On Wed, 8 Aug 2012, Jonas Maebe wrote:
(or is it possible?
After the body of the called routine has been parsed, it would be
possible in theory (with indeed all the caveats the compiler would
have to take care of such as side effects -- note that these may
include non-obvious side-effects, such as potential overflow
exceptions and invalid pointer accesses).
You'd need to check the caller routine as well, values for parameters
might
still be used after the call to the function.
Dbg:=SomeCalculatingFunction+' Some message';
DebugLn(Dbg); // If debugln is empty, you don't need dbg for it, so
the previous call is not needed.
In this case only the reference to the variable (but not the constant)
would be dropped.
So if the next writeln wasnt there, then the well known note "variable
assigned but never read" would be given.
Of course this would not help the debugln, except the author could then
place the string const directly into the call...
Writeln(dbg); // but you need it here.
And you don't know what SomeCalculatingFunction may have as side effects.
Yes, I did indicate that.
function calls can not be removed.
Again Except: if a special mode flag was introduced that could toggle
this (default off). It is the same as with bool eval
Of course, all highly theoretical.
I still use ifdefs for debug messages, and have a template to quickly
insert :
{$ifdef debugmsg}SendDebug('|');{$endif debugmsg}
Yes, but it adds a lot of extra text to the source. If therce are
frequent debugln calls.
- Either the debugln lines get very long,
- Or 2 extra lines are added for teh ifdef/endif and that stretches the
length of the procedure, and how much fits on a screen
Of course the IFDEF does highlight in the IDE telling you where the
debugln are
But I already have the idea to allow highlighting user specified words
(and then all debugln can highlight too)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does FPC optimize unused parameters ?
michael.vancanneyt wrote on Wed, 08 Aug 2012:
On Wed, 8 Aug 2012, Jonas Maebe wrote:
After the body of the called routine has been parsed, it would be
possible in theory (with indeed all the caveats the compiler would
have to take care of such as side effects -- note that these may
include non-obvious side-effects, such as potential overflow
exceptions and invalid pointer accesses).
You'd need to check the caller routine as well, values for parameters might
still be used after the call to the function.
There's a difference between not loading/evaluating expressions passed
as a parameter, and completely eliminating the program slice that
contributed to calculating every value used in the parameter
expression. Obviously, the latter has much more stringent requirements.
I still use ifdefs for debug messages, and have a template to
quickly insert :
{$ifdef debugmsg}SendDebug('|');{$endif debugmsg}
This way, there is no extra code in my final build.
It's possible to do that in a more compact way with a macro (the
following is used in a couple of places in the RTL):
{$macro on}
{$ifdef debugmsg}
{$define CallSendDebug:=SendDebug}
{$else}
{$define CallSendDebug:=//}
{$endif}
CallSendDebug('|');
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does FPC optimize unused parameters ?
Martin wrote on Wed, 08 Aug 2012: That makes me wonder how inlining works? Doesn't inlining need to know the body? Yes. Before the body is known, an "inline" function does not get inlined. That's why units are sometimes recompiled even if you don't change anything, because in case of circular (implementation) unit references, more inline bodies may be known during subsequent compilations. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does FPC optimize unused parameters ?
On Wed, 8 Aug 2012, Jonas Maebe wrote:
Martin wrote on Wed, 08 Aug 2012:
Out of curiosity. Is there an optimization like this
[removing calculation/load of unused parameters]
No.
(or is it possible?
After the body of the called routine has been parsed, it would be possible in
theory (with indeed all the caveats the compiler would have to take care of
such as side effects -- note that these may include non-obvious side-effects,
such as potential overflow exceptions and invalid pointer accesses).
You'd need to check the caller routine as well, values for parameters might
still be used after the call to the function.
Dbg:=SomeCalculatingFunction+' Some message';
DebugLn(Dbg); // If debugln is empty, you don't need dbg for it, so the
previous call is not needed.
Writeln(dbg); // but you need it here.
And you don't know what SomeCalculatingFunction may have as side effects.
Function SomeCalculatingFunction : String;
begin
LastKnownAlive:=Now;
Result:=DateTimeToStr(LastKnownAlive);
end;
If the call to this function is optimized away, LastKnownAlive is not updated
correctly
any more...
Of course, all highly theoretical.
I still use ifdefs for debug messages, and have a template to quickly insert :
{$ifdef debugmsg}SendDebug('|');{$endif debugmsg}
This way, there is no extra code in my final build.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does FPC optimize unused parameters ?
On 08/08/2012 15:37, Jonas Maebe wrote: [removing calculation/load of unused parameters] No. I assumed that... (or is it possible? After the body of the called routine has been parsed, it would be possible in theory (with indeed all the caveats the compiler would have to take care of such as side effects -- note that these may include non-obvious side-effects, such as potential overflow exceptions and invalid pointer accesses). I could have known that. I totally forgot it works on the declaration only. That makes me wonder how inlining works? Doesn't inlining need to know the body? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does FPC optimize unused parameters ?
Martin wrote on Wed, 08 Aug 2012: Out of curiosity. Is there an optimization like this [removing calculation/load of unused parameters] No. (or is it possible? After the body of the called routine has been parsed, it would be possible in theory (with indeed all the caveats the compiler would have to take care of such as side effects -- note that these may include non-obvious side-effects, such as potential overflow exceptions and invalid pointer accesses). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Does FPC optimize unused parameters ?
Out of curiosity. Is there an optimization like this (or is it possible?
procedure Foo(a:String; B: Integer); inline; // inline is optional
begin
// EMPTY
end;
This is a plain procedure, not a method, not overloaded, not virtual.
And the parameters are both not used in the procedure (But obviously
this might also apply for none empty, if params are not used)
somewhere else might be
Foo('hello world', 1);
or
Foo('hello world', CalcSomeInt());
At that point it could be known (especially if inlined?) that the params
are not used).
So the string constant would not be needed in the app.
If not inlined, there may still be a need to satisfy calling params ABI
or whatever... But if inlined, even the integer wasn't needed.
The CalcSomeInt may be wanted of course, for side effcts
Of course the question is who would write such code. But actually it happens
The LazLoggerDumy unit provides empty inline-able procedures. This
allows to write all the debugln in your app without plenty of $IFDEF.
Simply change the unit From LazLogger to LazLoggerDumy and logging is gone.
Of course it would be nice if FPC could drop as much of the not required
params as possible.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
