This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] RFC: Making control flow more explicit

On Mon, 2003-08-11 at 19:14, wrote:
> In message <>, Michael Ma
> tz writes:
>  >> Very very rarely within the DCE optimizer.
>  >
>  >Control dependence or postdoms also are necessary in if-conversion and for
>  >some edge probability predicators.
> Yup.  One of the unaddressed questions in my mind is whether or not it makes
> sense to compute postdoms once early in the SSA path and keep them up-to-date
> through the SSA optimizers or not.  We compute them on-demand in a few
> places, mostly in areas dealing with IF removal.
>  > Hmm, but maybe you're right and some
>  >other form of approximate but faster to calculate form of control
>  >dependence is enough.
> It's enough for tree-ssa-dce.c; I have no idea if it's suitable elsewhere.
> Hell, it took me a while to convince myself that what tree-ssa-dom.c was
> indeed safe.  It didn't take long to determine that what tree-ssa-dom.c
> does was faster than using true control dependence...  Let's call it an
> interesting surprise.
> The good news is that if we want to move to using true control dependence
> that it's a fairly simple change to lift the first few hundred lines out
> of ssa-dce.c and put them in tree-ssa-dce.c and tweak tree-ssa-dce.c to use
> them.

Well, the only thing we use the parent/control dependence information
for is removing/keeping control flow stmts. Currently, if there is a PHI
node after the control stmt, we can't remove it anyway.

We let the cfg cleanup routines actually remove control flow most of the
time now, do we not? And I beleive you also wanted a lighter-weight DCE.
So perhaps we ought to invoke DCE with a flag indicating whether to
consider control flow or not.

If you don't want control flow analyzed, DCE could simply assume all
control flow stmt's are necessary, and only looks at other stmts. This
should result in a fairly lightweight DCE. If you do want flow
considered, then we build the pdom info and handle control flow as well
(digging out your old patch perhaps?, although we do build PDOM info on
occassion already). 

I suspect we'd only need the flow considered during the very last call
before we go back to normal form. Even then, there is likely to be
deletable flow exposed by SSA->normal as PHI nodes are resolved into
copies or coalesced variables, so maybe we dont even need it then. Just
a cleanup afterwards. Maybe it would be handy to always turn on flow
analysis at -O3 or something...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]