Hi Mindaugas,
> > It looks very nice. Can youy add it to compiler?
> I thought that you'll find an easier way to generate these warnings
> using pExpr tree :) Like there was with push/pop optimisation with jump
> in between some time ago.
Unfortunately it's not possible without serious compiler modification :-(
Harbour takes one command compile it to pExpr tree, generates
PCODE and then remove expression tree. We do not have list of expressions
for whole function so it's not possible to create expression optimizer
which needs to operate on more then one line of code. In this case it's
necessary to analyze whole function body.
Current behavior reduce memory usage but also does not allow to introduce
optimizations between commands on expression level so many optimizations
have to be hardcoded as PCODE optimizer.
In current days memory usage is not a problem so it will be good to change
it but it will be necessary to make really deep modifications but as
result we can intorduce many other optimizations, f.e.:
local x
x := func1()
func2( x )
can be reduced to:
func2( func1( x ) )
> > Very nice job. I would like to ask to integrate it with compiler.
> > If you will need any help then I'll do what I can.
> I'll try to add to compiler, but I need to rethink conditions of
> warnings, and code optimisation. There is always a danger for locals to
> be infected by references.
> xLocal := xParam // not useless assignment if xParam is reference
> xLocal := 1
It is useless assignment because even if xParam is reference then
this reference is not assigned to xLocal but only value which is
pointed by reference so later xLocal := 1 does not change it.
> And how about that?:
> xLocal := f()
> xLocal := 1
> Should we generate warning in these cases?
I think yes. In theory function can return reference hacking iif()
pseudo function or array item:
local xVar
return iif( .t., @xVar, )
or:
local xVar
return { @xVar }[ 1 ]
but it's side effect of Clipper syntax which can corrupt VM stack
not sth designed intentionally so it should not block us.
Anyhow in the future we should think about adding method to pacify
some warnings by programmer (sth like HB_SYMBOL_UNUSED()) but as long
as we will make the optimization analyzing final PCODE it will be hard
to pass such information from source code. F.e. HB_SYMBOL_UNUSED()
does not generate any PCODE and it's fully reduced. Now it's reduced
at PCODE optimization level but in this case it can be easy done in
expression optimizer. If we will make it in such way then PCODE optimizer
will not receive any information about variable usage and used
HB_SYMBOL_UNUSED() in source code.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
