[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optimizations (was Re: [DotGNU]All my tests work)
From: |
Rhys Weatherley |
Subject: |
Re: Optimizations (was Re: [DotGNU]All my tests work) |
Date: |
Wed, 20 Nov 2002 22:30:17 +1000 |
Gopal V wrote:
> > There are some possibilities for "reduction in strength" and
> > "arithmetic equivalence" optimizations. e.g. converting "x * 2"
> > into "x << 1" if "x" is an integer type. This would probably need
> > to be handled in "cg_arith.tc",
>
> Hmm... I would rather do it in cs_oper.tc ? ... Calling EvalConst on the
> codegen seems ugly to me .... Considering the fact that we already do a
> constant folding (ILEvalOperator) step in the SemAnalysis ?..
If it is done in codegen, then the C compiler will also get the
optimizations for free, but if it is done during semantic analysis,
then it will need to be replicated for each language.
> > until we have better dynamic flow analysis in the compiler (right
> > now we have none).
>
> /me dreams on about doing a CSOptmizerIsInVariant(info, node->body, var) ;
> and CSOptmizerIsUnused(info, node->body, var); .... which in my very humble
> opinion are very similar to ILNodeEndsInFlowChange.. (assign expressions
> with var in lvalue and out or ref parameters seem the only variant cases ,
> and the second could use ILNode_Identifier's semanalysis ?).
Yes, they are similar, with a bit more house-keeping required.
> But well ... I'll leave cscc clean of such hacks until 0.4.8 .. (when is
> the big release Rhys ? ....)
This weekend perhaps, if everyone is happy with the state of their
code at the end of the week.
> > If someone wants to look into optimizations, I suggest adding an
> > "optimize_flag" to "ILGenInfo" (cg_gen.h), and then start looking
> > into simple arithmetic reduction in strength optimizations. That
> > will be a good starting point to get experience before thinking
> > about the more complex cases.
>
> Ok ... I'm on the Multiply and Divide operations conversion to shifts..
>
> Hmm... also need to make sure we don't mess up actual compilation here,
> because cscctest won't do much good for this ....
Hence the "optimize_flag", which won't be set initially for cscctest.
So, it will fall back to the original behaviour. We'll deal with
testing the optimizer in cscctest later.
Cheers,
Rhys.