local data flow

[Joern RENNECKE]

Kenneth Zadeck wrote:

>I would be very careful to tread here.  regstack is a can of worms and
>not very good worms.  We have had a lot of trouble retrofitting better
>dataflow into regstack because of the fragile nature of it's
>implementation. 
>  
>
Well, the approach so far has been 'don't touch change any register 
allocation
for stack regs after reg_stack'.  I.e. if cross-jumping sees any stack 
regs, it
considers only literal matches.  That should be safe.
The only question that arises here is how we should compute the regsets
when we split a block.

>If you think that your cross jumping would be good to do as an
>interleaved pass to if conversion, it is possible to see the benefit
>there.
>
There seems to be a misunderstanding here.  I have code that is supposed
to be used both by if-conversion and by crossjumping.  But I have not 
proposed
to run both optimizations interleaved, not am I aware of any benefit 
that would
have.
Most of the higher-level if-conversion transformations can only be done
before register allocation.
Our corss-jumping code is supposed to be run after register allocation,
and I suspect running it before register allocation (which I believe 
would require
some changes first) would be rather bad for speed optimizations - 
basically the
antithesis of treegion formation.
 

>However, I think that the code gets hardened a lot by register
>allocation in it is difficult for me to see how heroic transformations
>are going to be really useful after that pass. 
>
>Anyway, many compilers do label the stack and do dataflow on the
>individual stack elements.  GCC is problematic because most of the stack
>off are set in register allocation, and in truth it really is too late
>to get much benefit after that pass.  But it is not hard to define a
>problem that did label the stack elements.
>  
>
I'm really not very interested in doing optimizations on reg-stack 
accesses.  I just
want to be able to do some more intelligent crossjumping, which happens 
to take
place after regstack.  Only one processor family uses regstack, and even 
there
it is only relevant in fp-heavy code, and might become obsolescent 
because of
saner IEEE behaviour and pipelinabiliy of SSE instructions.