[tree-ssa] switch_expr lowering, part 1

[Jan Hubicka]

> On Thu, Oct 30, 2003 at 11:57:33PM +0100, Jan Hubicka wrote:
> > (my current problem is that I need old cfg_cleanup before loop to keep
> > loop notes right)
> 
> Why bother?  We're currently *generating* loop notes now, always.
> We can delay that until immediately before the old loop pass runs.

Yes, I was thinking about this too.
One drawback is that we need to re-roder the loop header duplication
pass and CSE1 as we can't generate that note.  Not a big deal, but it
has turned out to be blocker when I intended to do this last time.

OK, I will probably start moving to cfglayout RTL on tree-SSA pass by
pass now, OK?  (majority of passes should be trivial but you know that
there will be showstoppers).
> 
> > What is the uneasy stuff?
> 
> Finish lowering BIND_EXPR.  Finish statement_list patch.
> Not *difficult* so much as tedious.

I see.
> 
> > As I remember, Zdenek was mentioning that the major problem is increased
> > memory usage when all local array are allocated at the beggining of
> > function body.  With current scheme of scopes we can share memory used
> > by both.  But provided how many dificulties this brings, I think we can
> > give this up and later think about implementing kind of stack-allocation
> > algorithm later in the tree-SSA compilation path.
> 
> No, I'm suggesting neither that scopes be dropped nor variables be
> moved to the outermost scope.  Just need to somehow be rid of the
> BIND_EXPR out of the representation.

Problem is that the BIND_EXPR implicitly represent lifetime interval of
the global variable.  We all know that any attempt to represent
intervals in IL code using notes or whatever else leads to catastroph.
We will always end up breaking these intervals and moving code out of
them or losing optimization oppurtunities.

The lifetime is only used for re-using allocated stack slots so that is
why I would suggest to simply drop it for now and possibly later do real
conflict graph construction just before RTL generation to lay out the
datstructures in good way and add the new aliasing conflicts.

The use of scopes for debug information can remain - we simply attach
scopes to the insn locators like and keep their tree separately same way
we do for RTL.  

Honza
> 
> Not sure exactly how this needs to work, just yet.  Possibly we
> mark basic blocks with the associated BLOCK and don't allow bb's
> from different blocks to be merged.
> 
> 
> r~